home *** CD-ROM | disk | FTP | other *** search
/ MacTech 1 to 12 / MacTech-vol-1-12.toast / Reference / the cmsp digests ('94-'97) / csmp digest Vol 3 No 136 < prev    next >
Text File  |  1996-02-15  |  90KB  |  2,380 lines

  1. C.S.M.P. Digest             Thu, 15 Feb 96       Volume 3 : Issue 136
  2.  
  3. Today's Topics:
  4.  
  5.         ATM Interface?
  6.         Controls in GWorlds not drawing properly?
  7.         Format 'drag' resource wanted
  8.         How to walk the driver table?
  9.         OpenDoc and C (not ++)
  10.         PICT output from CGrafPort (plea for help)
  11.         Pascal or C++?
  12.         PixMap pmVersion field
  13.         TextEdit: how to stay in one line?
  14.         TransSkel 3.24 is available (CW 8 support added)
  15.         WorldScript, UniCode & Cross-Platform ?
  16.         [Ann] The alt.sources.mac WWW Archive
  17.         [src] Grant's CGI Framework beta 13 (mac C source)
  18.         calculating height of a text box
  19.  
  20.  
  21.  
  22. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  23. (pottier@clipper.ens.fr).
  24.  
  25. The digest is a collection of article threads from the internet
  26. newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
  27. csmp.games. It is designed for people who read news semi-regularly and
  28. want an archive of the discussions.  If you don't know what a
  29. newsgroup is, you probably don't have access to it. Ask your systems
  30. administrator(s) for details. If you don't have access to news, you
  31. may still be able to post messages to the group by using a mail server
  32. like anon.penet.fi (mail help@anon.penet.fi for more information).
  33.  
  34. Each issue of the digest contains one or more sets of articles (called
  35. threads), with each set corresponding to a 'discussion' of a particular
  36. subject.  The articles are not edited; all articles included in this digest
  37. are in their original posted form (as received by our news server at
  38. nef.ens.fr).  Article threads are not added to the digest until the last
  39. article added to the thread is at least two weeks old (this is to ensure that
  40. the thread is dead before adding it to the digest).  Article threads that
  41. consist of only one message are generally not included in the digest.
  42.  
  43. The digest is officially distributed by two means, by email and ftp.
  44.  
  45. If you want to receive the digest by mail, send email to listserv@ens.fr
  46. with no subject and one of the following commands as body:
  47.     help                                Sends you a summary of commands
  48.     subscribe csmp-digest Your Name     Adds you to the mailing list
  49.     signoff csmp-digest                 Removes you from the list
  50. Once you have subscribed, you will automatically receive each new
  51. issue as it is created.
  52.  
  53. The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
  54. Questions related to the ftp site should be directed to
  55. scott.silver@dartmouth.edu.
  56.  
  57. -------------------------------------------------------
  58.  
  59. >From chance59@wavenet.com (R. T. Chancellor)
  60. Subject: ATM Interface?
  61. Date: Sat, 27 Jan 1996 19:08:33 -0700
  62. Organization: ATMnet, LLC San Diego, CA
  63.  
  64. Does anyone know if a library and interface files is available for Adobe
  65. Type Manager? I used a library and .h file several years ago, but when I
  66. went looking for a newer version, all I could find was a .h file and no
  67. library. I have already tried Adobe (like pulling teeth). If you know
  68. where I can obtain it, please let me know.
  69.  
  70. Thanks in advance.
  71.  
  72.  
  73. Robert Chancellor
  74. chance59@wavenet.com
  75.  
  76. +++++++++++++++++++++++++++
  77.  
  78. >From mouser@zercom.net (Martin-Gilles Lavoie)
  79. Date: Mon, 29 Jan 1996 09:32:01 -0500
  80. Organization: Groupimage, inc.
  81.  
  82. In article <chance59-2701961908330001@la-dial1-20.wavenet.com>,
  83. chance59@wavenet.com (R. T. Chancellor) wrote:
  84.  
  85. > Does anyone know if a library and interface files is available for Adobe
  86. > Type Manager? I used a library and .h file several years ago, but when I
  87. > went looking for a newer version, all I could find was a .h file and no
  88. > library. I have already tried Adobe (like pulling teeth). If you know
  89. > where I can obtain it, please let me know.
  90. > Thanks in advance.
  91.  
  92. I have a copy for 68K code.  As far as I know, no one has publicaly
  93. published a PPC native version yet.  It dates back a little, but works
  94. fine.  Here's where you can find it:
  95.  
  96. <ftp://ftp.mv.us.adobe.com/pub/adobe/Programs/MacATM30headers.sea.hqx>
  97.  
  98. For current documentation of the ATM Macintosh C interface download:
  99.  
  100. <ftp://ftp.mv.us.adobe.com/pub/adobe/DeveloperSupport/TechNotes/5072.ATM_Adv_Mac.pdf>
  101.  
  102.  
  103. Have fun.
  104.  
  105. MGL
  106.  
  107. +++++++++++++++++++++++++++
  108.  
  109. >From dpolasch@apple.com (Dave Polaschek)
  110. Date: Wed, 31 Jan 1996 23:10:01 GMT
  111. Organization: Apple Computer, Inc
  112.  
  113. In article <chance59-2701961908330001@la-dial1-20.wavenet.com>,
  114. chance59@wavenet.com (R. T. Chancellor) wrote:
  115.  
  116. >Does anyone know if a library and interface files is available for Adobe
  117. >Type Manager? I used a library and .h file several years ago, but when I
  118. >went looking for a newer version, all I could find was a .h file and no
  119. >library. I have already tried Adobe (like pulling teeth). If you know
  120. >where I can obtain it, please let me know.
  121.  
  122. It's documented in Adobe Tech Note #5072, which should be available at or
  123. near <ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PSfiles/>
  124.  
  125. -DaveP
  126.  
  127. -- 
  128. "Mr. Tick, can you destroy the Earth?"
  129. "Egads! I hope not! That's where I keep all my stuff!"
  130. Dave Polaschek - home:davep@eworld.com work:dpolasch@apple.com
  131.  
  132. ---------------------------
  133.  
  134. >From jeffwest@204.137.144.227 (jeffwest)
  135. Subject: Controls in GWorlds not drawing properly?
  136. Date: 28 Jan 1996 19:47:04 GMT
  137. Organization: zNET
  138.  
  139. I am using an offscreen GWorld to do my window updates in before I
  140. copybit it into the actual window. I am experiencing a very strange
  141. side-effect when using certain controls in the window.
  142.  
  143. I set the Control's cntrlOwner field to my offscreen GWorld and use
  144. Draw1Control to draw the control. This works fine for any control that
  145. uses a CDEF without any variants, i.e. a standard push-button. However,
  146. if the control uses a variant of a CDEF then the control always draws
  147. using the CDEF without the variant. Example: I create a chechbox using
  148. a procdef of 1. I set it's cntrlOwner field to my offscreen GWorld and
  149. call Draw1Control and then copybit it over to the window and it appears
  150. as a standard push-button. I then click on it and it redraws itself as
  151. a checkbox.
  152.  
  153. I tried this with a custom CDEF I had the source code for and found out
  154. through the debugger that the CDEF would always get passed a variant of
  155. 0 when it is being drawn in an offScreen port. I beleive this might
  156. have something to do with the fact that a GWorld does not have a
  157. control list hanging off of it like a window does. (MacsBug shows that
  158. Draw1Control call a couple of other ControlManager routines, including
  159. GetCntlVariant before it actually draws the control.
  160.  
  161. Does anyone know of a fix / work around for this problem? Am I doing
  162. something wrong?
  163.  
  164. Any help would be greatly appreciated.
  165.  
  166. Thanks,
  167.  
  168. Jeff West
  169.  
  170. +++++++++++++++++++++++++++
  171.  
  172. >From dflatin@magnus.acs.ohio-state.edu (Dan Flatin)
  173. Date: Mon, 29 Jan 1996 12:45:20 -0600
  174. Organization: Department of Physics, The Ohio State University
  175.  
  176. You might try drawing the controls directly to the window, and mask out
  177. their rects when you do the CopyBits. That has worked for me.
  178.  
  179. -- 
  180. Dan Flatin
  181. Department of Physics
  182. The Ohio State Unviersity
  183.  
  184. +++++++++++++++++++++++++++
  185.  
  186. >From jeffwest@204.137.144.227 (jeffwest)
  187. Date: 1 Feb 1996 02:03:06 GMT
  188. Organization: zNET
  189.  
  190. In article <dflatin-2901961245200001@slip1-26.acs.ohio-state.edu>
  191. dflatin@magnus.acs.ohio-state.edu (Dan Flatin) writes:
  192.  
  193. > You might try drawing the controls directly to the window, and mask out
  194. > their rects when you do the CopyBits. That has worked for me.
  195.  
  196. Thanks, but I looked at the source for PowerPlant to see if and how
  197. they were handling this and discovered a great workaround.
  198.  
  199. Their solution is to leave the control's owner alone and, in the middle
  200. of drawing to your offscreen port, switch the port to the control's
  201. window, open a picture, draw the control, close the picture, switch the
  202. port back to the offscreen port and then draw the picture of the
  203. control in place of the control.
  204.  
  205. It works great!
  206.  
  207. I plan on checking out the rest of the PowerPlant code to see what
  208. other neat tricks they have up their sleeve.
  209.  
  210.  
  211. Thanks for your response.
  212.  
  213. Regards,
  214.  
  215. Jeff West
  216. Logical Inventions
  217.  
  218. ---------------------------
  219.  
  220. >From jbruyndonckx@waveresearch.com (Jan Bruyndonckx)
  221. Subject: Format 'drag' resource wanted
  222. Date: Tue, 23 Jan 1996 09:14:42 +0100
  223. Organization: Cratylus Corp
  224.  
  225. Hi,
  226.  
  227. I'm looking for the full description of the 'drag' resource.
  228. This resource is used by the drag & drop manager in clippings files.
  229. I know the meaning of some fields, but I'd like to know the meaning of
  230. each field.
  231.  
  232. Has anyone figured it out?
  233.  
  234. Thanks,
  235.  
  236. Jan Bruyndonckx
  237. Wave Research
  238.                                      \|/
  239.                                     (o o)
  240. ________________________________oOo__(_)__oOo_________________________________
  241. | Jan Bruyndonckx          And what is good, Phaedrus, And what is not good, |
  242. |                                 Need we ask anyone to tell us these things |
  243. | e-mail: jbruyndonckx@waveresearch.com                          (R.
  244. Pirsig) |   
  245. l____________________________________________________________________________l
  246.  
  247. +++++++++++++++++++++++++++
  248.  
  249. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro)
  250. Date: Mon, 29 Jan 1996 13:38:10 +1300
  251. Organization: University of Waikato
  252.  
  253. In article <jbruyndonckx-2301960914430001@194.7.68.21>,
  254. jbruyndonckx@waveresearch.com (Jan Bruyndonckx) wrote:
  255.  
  256. >I'm looking for the full description of the 'drag' resource.
  257. >This resource is used by the drag & drop manager in clippings files.
  258. >I know the meaning of some fields, but I'd like to know the meaning of
  259. >each field.
  260.  
  261. It seems pretty simple. The initial part looks like this:
  262.  
  263.    TYPE
  264.       DragResourceHeader =
  265.          RECORD
  266.             VersionNumber : LongCard; (* = 1 *)
  267.             Unused1, Unused2 : LongCard; (* always 0 *)
  268.             NrFlavors : LongCard;
  269.            (* Flavor : ARRAY [1 .. NrFlavors] OF DragResourceEntry *)
  270.          END (*RECORD*);
  271.  
  272. where NrFlavors is the number of flavour entries. This is immediately
  273. followed by that number of entries, of the following format:
  274.  
  275.    TYPE
  276.       DragResourceEntry =
  277.          RECORD
  278.             FlavorType : OSType;
  279.             ResourceID : LongInt;
  280.             Unused1, Unused2 : LongCard; (* always 0 *)
  281.          END (*RECORD*);
  282.  
  283. FlavorType is the flavour type as well as the type of the resource
  284. containing the flavour data. ResourceID is the ID of the resource.
  285.  
  286. All the clipping files I've seen use 128 as the ID for all resources, and
  287. I've successfully done the same in clipping files created by my
  288. ClipStation utility.
  289.  
  290. Clipping files have four different file types: "clpp" for picture
  291. clippings, "clpt" for text clippings, "clps" for sound clippings, and
  292. "clpu" for everything else.
  293.  
  294. ---------------------------
  295.  
  296. >From alex <netman@kudonet.com>
  297. Subject: How to walk the driver table?
  298. Date: Fri, 26 Jan 1996 14:04:58 -0800
  299. Organization: NASA Ames Research Center
  300.  
  301. I'm a relatively new Mac programmer trying to write an installer
  302. and can't figure out how to walk the driver table to search for
  303. previously installed components. Can someone help me out?
  304. thanks in advance,
  305. alex 
  306. netman@kudonet.com
  307.  
  308. +++++++++++++++++++++++++++
  309.  
  310. >From <williamt@aloha.com>
  311. Date: 28 Jan 1996 19:15:57 GMT
  312. Organization: FlexNet Inc, HAWAII
  313.  
  314. alex <netman@kudonet.com> wrote:
  315. >I'm a relatively new Mac programmer trying to write an installer
  316. >and can't figure out how to walk the driver table to search for
  317. >previously installed components. Can someone help me out?
  318. >thanks in advance,
  319. >alex 
  320. >netman@kudonet.com
  321.  
  322. I'm sure this started as Apple example code some time back.
  323. E-mail me if it doesn't make sense:
  324.  
  325. short   GetUnusedDrvrRefNum (void)
  326. {
  327.         AuxDCEPtr       *unitTable;
  328.         short           unitEntryCount;
  329.         short           unitNumber;
  330.         short           drvrRefNum = 0; /* default to no entry found */
  331.         
  332.         unitTable = (AuxDCEPtr *)GetUnitTableBase();
  333.         unitEntryCount = GetUnitEntryCount();
  334.         
  335.         /* Look for the first empty entry */
  336.         unitNumber = kMinUnitNum;
  337.         while (unitNumber < unitEntryCount) {
  338.                 if (unitTable[unitNumber] == nil) { /* Find an empty entry? */ 
  339.                         /* Yes, then calculate its driver reference number */ 
  340.                         drvrRefNum = -1 * (unitNumber +1);
  341.                         break;
  342.                 }
  343.                 else
  344.                         ++unitNumber;
  345.         }
  346.         
  347.         return (drvrRefNum);
  348. }
  349.  
  350.  
  351.  
  352. ---------------------------
  353.  
  354. >From jhuber@optik.eng.yale.edu (John Huber)
  355. Subject: OpenDoc and C (not ++)
  356. Date: Mon, 29 Jan 1996 16:57:02 -0500
  357. Organization: Yale University, Dept of EE
  358.  
  359. I've got a silly question...
  360.  
  361. I dabble in C programming (even wrote a couple of little applications with
  362. all that interface stuff:), however, I've never done C++ (though I did
  363. flip through a Primer once). Anyway, is OpenDoc accessible via C, or does
  364. one have to bite the bullet and learn C++ (it's a time issue for me).
  365.  
  366. Thanks,
  367. John
  368.  
  369. +++++++++++++++++++++++++++
  370.  
  371. >From jeremy@dewey.soe.berkeley.edu (Jeremy Roschelle)
  372. Date: 31 Jan 1996 16:08:02 GMT
  373. Organization: SimCalc
  374.  
  375. In article <jhuber-2901961657020001@hood.eng.yale.edu>,
  376. jhuber@optik.eng.yale.edu (John Huber) wrote:
  377.  
  378. >I've got a silly question...
  379. >
  380. >I dabble in C programming (even wrote a couple of little applications with
  381. >all that interface stuff:), however, I've never done C++ (though I did
  382. >flip through a Primer once). Anyway, is OpenDoc accessible via C, or does
  383. >one have to bite the bullet and learn C++ (it's a time issue for me).
  384.  
  385. It is accesible in C, and there is even a sample part in C I think.
  386.  
  387. jeremy
  388.  
  389. jeremy              > > > > > > > > > > * Jeremy Roschelle
  390.                                         * SimCalc Project
  391.                                         * 4104 24th Street #344
  392.                                         * San Francisco CA 94114
  393.                                         * 415 695.2801
  394.  
  395. +++++++++++++++++++++++++++
  396.  
  397. >From jeremy@dewey.soe.berkeley.edu (Jeremy Roschelle)
  398. Date: 31 Jan 1996 16:10:10 GMT
  399. Organization: SimCalc
  400.  
  401. In article <jhuber-2901961657020001@hood.eng.yale.edu>,
  402. jhuber@optik.eng.yale.edu (John Huber) wrote:
  403.  
  404. >I've got a silly question...
  405. >
  406. >I dabble in C programming (even wrote a couple of little applications with
  407. >all that interface stuff:), however, I've never done C++ (though I did
  408. >flip through a Primer once). Anyway, is OpenDoc accessible via C, or does
  409. >one have to bite the bullet and learn C++ (it's a time issue for me).
  410.  
  411. It is accesible in C, and there is even a sample part in C I think.
  412.  
  413. jeremy
  414.  
  415. jeremy              > > > > > > > > > > * Jeremy Roschelle
  416.                                         * SimCalc Project
  417.                                         * 4104 24th Street #344
  418.                                         * San Francisco CA 94114
  419.                                         * 415 695.2801
  420.  
  421. +++++++++++++++++++++++++++
  422.  
  423. >From jayfar@netaxs.com (Jay Farrell)
  424. Date: Wed, 31 Jan 1996 13:12:29 -0500
  425. Organization: Jayfar's Web
  426.  
  427. In article <4eo492$j7o@slip.net>, jeremy@dewey.soe.berkeley.edu (Jeremy
  428. Roschelle) wrote:
  429.  
  430. | In article <jhuber-2901961657020001@hood.eng.yale.edu>,
  431. | jhuber@optik.eng.yale.edu (John Huber) wrote:
  432. | >I've got a silly question...
  433. | >
  434. | >I dabble in C programming (even wrote a couple of little applications with
  435. | >all that interface stuff:), however, I've never done C++ (though I did
  436. | >flip through a Primer once). Anyway, is OpenDoc accessible via C, or does
  437. | >one have to bite the bullet and learn C++ (it's a time issue for me).
  438. | It is accesible in C, and there is even a sample part in C I think.
  439.  
  440. Which reminds me of an earlier question I asked the response to which was
  441. not very encouraging.  What about the various public domain languages that
  442. some of us choose to dabble in?  The book (just out from Apple; forgot the
  443. exact title) claims you can do OpenDoc in *any* language, thanks to IDL.
  444.  
  445. How?  Could somebody point me to where in the voluminous docs I can puzzle
  446. this out?
  447.  
  448. TIA,
  449. Jayfar
  450.  
  451.    ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  452.   ////   The Mops Page    <URL:http://www.netaxs.com/~jayfar/mops.html>    ////
  453.  ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  454. ////   Mops is Mike Hore's freeware Forth/Smalltalk hybrid for Macintosh ////
  455. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  456.   Jay Farrell     jayfar@netaxs.com        Philadelphia, Pennsylvania, USA
  457.  
  458. +++++++++++++++++++++++++++
  459.  
  460. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  461. Date: 01 Feb 1996 17:07:19 GMT
  462. Organization: Integrated Systems Laboratory, ETH, Zurich
  463.  
  464. In article <jayfar-3101961312290001@downtown1-33.slip.netaxs.com>, jayfar@netaxs.com (Jay Farrell) writes:
  465.  
  466. > In article <4eo492$j7o@slip.net>, jeremy@dewey.soe.berkeley.edu (Jeremy
  467. > Roschelle) wrote:
  468.  
  469. > | In article <jhuber-2901961657020001@hood.eng.yale.edu>,
  470. > | jhuber@optik.eng.yale.edu (John Huber) wrote:
  471. > | 
  472. > | >I've got a silly question...
  473. > | >
  474. > | >I dabble in C programming (even wrote a couple of little applications with
  475. > | >all that interface stuff:), however, I've never done C++ (though I did
  476. > | >flip through a Primer once). Anyway, is OpenDoc accessible via C, or does
  477. > | >one have to bite the bullet and learn C++ (it's a time issue for me).
  478. > | 
  479. > | It is accesible in C, and there is even a sample part in C I think.
  480.  
  481. > Which reminds me of an earlier question I asked the response to which was
  482. > not very encouraging.  What about the various public domain languages that
  483. > some of us choose to dabble in?  The book (just out from Apple; forgot the
  484. > exact title) claims you can do OpenDoc in *any* language, thanks to IDL.
  485.  
  486. > How?  Could somebody point me to where in the voluminous docs I can puzzle
  487. > this out?
  488.  
  489. To do OpenDoc, you have to be able to do SOM. SOM is remarkably language
  490. neutral, however, the current Mac implementation lacks some key components
  491. to deliver on that promise:
  492.  
  493.  - For static languages (like Pascal), the SOM compiler lacks the ability to
  494.    hook into the Emitter framework. On other platforms, apparently you can
  495.    write your own backend to the IDL compiler to make it generate stubs in
  496.    whatever language you want to use.
  497.  - For dynamic languages (Perl, Tcl, Scheme, Frontier, Mops?), the support for
  498.    reflexiveness is not yet complete enough. In principle, SOM has mechanisms
  499.    to find out all type information at runtime, but I understand these have
  500.    not yet been implemented on the Mac.
  501.  
  502. So the key problems seem to be in the area of SOM, and Apple seems not to be
  503. overly motivated to remedy them.
  504.  
  505. Matthias
  506.  
  507. - ---
  508. Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  509.    "Have you heard of the new Cambridge compilers ? They distribute
  510.     gear-wear much more evenly"
  511.         -- William Gibson/Bruce Sterling, _The Difference Engine_
  512.  
  513.  
  514. ---------------------------
  515.  
  516. >From subtle@progsoc.uts.edu.au (Paul Mclachlan)
  517. Subject: PICT output from CGrafPort (plea for help)
  518. Date: Mon, 22 Jan 1996 17:14:31 +1000
  519. Organization: Microplex Pty Ltd
  520.  
  521. I've recently started programming on the macintosh environment with
  522. Codewarrior, and have, I'm afraid, run into a small wall.
  523.  
  524. I can read in a PICT file and display it, however I'm having a lot of
  525. trouble then when trying to write it back out to disk again.  I've read
  526. almost all of the ColorQuickdraw section of Inside Macintosh, but
  527. something is eluding me.
  528.  
  529. At the moment, I can output a perfectly good PICT file, provided I don't
  530. want any images in it.  That is, I can move the cursor and draw lines, and
  531. output *that* to a PICT file, but when I try to use CopyBits(), for some
  532. strange reason, it fails to work.
  533.  
  534. Perhaps I'm being a bit too fancy.  What I'm actually trying to do is
  535. store whats currently displayed on the screen (its built up of layered
  536. images - to write them over one another would use more disk space than
  537. required?), so I attempt to use CopyBits to basically copy the PixMap onto
  538. itself.
  539.  
  540. Now... it says in the manual that if I want to copybits like that I should
  541. change to Global co-ordinates, and I've tried that - I've also
  542. experiemented with a variety of regions.
  543.  
  544. Whats got me stumped is that when I read in the PICT originally, I can
  545. just hold onto that handle that I've got, and write it back out perfectly
  546. - if I try to use OpenCPicture to record it again - well... I'm obviously
  547. doing something wrong.
  548.  
  549. If anyone has written something like this, or has some code that does
  550. something similar that I could take a look at, I'd greatly appreciate it. 
  551. Failing that, if someone could just yell 'You're doing it wrong!' and push
  552. me in the right direction... ;p~
  553.  
  554. Thanks,
  555. Paul
  556.  
  557. - -
  558. Paul Mclachlan
  559. paulm@access.com.au
  560.  
  561. #include <stddisclaimer.h>
  562.  
  563. +++++++++++++++++++++++++++
  564.  
  565. >From Carl R. Osterwald <carl_osterwald@nrel.gov>
  566. Date: 25 Jan 1996 17:32:40 GMT
  567. Organization: National Renewable Energy Laboratory
  568.  
  569. In article <subtle-2201961714420001@203.18.229.38> Paul Mclachlan,
  570. subtle@progsoc.uts.edu.au writes:
  571.  
  572. >At the moment, I can output a perfectly good PICT file, provided I don't
  573. >want any images in it.  That is, I can move the cursor and draw lines, and
  574. >output *that* to a PICT file, but when I try to use CopyBits(), for some
  575. >strange reason, it fails to work.
  576.  
  577. One thing that can cause this is lack of enough memory.  When recording
  578. a picture with OpenPicture() / ClosePicture(), it can be difficult to
  579. determine if any errors occured.  You can try looking at the size of the
  580. PicHandle to see if it is greater than 10 bytes, and if the picFrame is
  581. equal to the rectangle used when creating the PICT.  I have found that
  582. these will not be true if the picture creation failed.
  583.  
  584. +++++++++++++++++++++++++++
  585.  
  586. >From Binky the Wonderwhorse <binky@mmcorp.com>
  587. Date: 29 Jan 1996 17:35:13 GMT
  588. Organization: MultiMedia Corporation
  589.  
  590. lo,
  591.  
  592. try something like this (this routine is taken from something I did last
  593. year...it works as is)
  594. there might be the odd call or two that might not work cuz the project
  595. had over 200 files in it and I really can't be bothered to go hacking
  596. around for the sources...sorry, but theres enough here to get you going.
  597.  
  598. Hope this helps.
  599. Binky
  600.  
  601. //      =============================================================
  602. //      =       PicHandleToPICTfile                                                                             =
  603. //      =============================================================
  604. //      =       You give me a PicHandle, a filename and a volume to     =
  605. //      =       it on and I'll do the donkey work.  Its a simple                =
  606. //      =       routine but then so is waking up...so why is waking up  =
  607. //      =       so damned difficult?  The easiest things are the                =
  608. //      =       hardest - least thats what I think                                              =
  609. //      =============================================================
  610. #define kNearAsDammitEmptyHandleSize 4
  611. #define kPictCreatorType '????'
  612. #define kPictureType 'PICT'
  613.  
  614. Boolean
  615. PicHandleToPICTfile(const PicHandle     thePichandle, const Str255
  616. theFilename, const short        volumeRefNum)
  617. {
  618.         Boolean                 result = FALSE;
  619.         OSErr                   iErr = noErr;
  620.         short                   myFileRef = 0, myResFile = 0,saveRes;
  621.         char                    pictHeader[512];
  622.         long                    byteCount = kPICTHeaderSize;
  623.         FSSpec                  myFSSpec;
  624.         PicHandle               theThumbnail =
  625. (PicHandle)NewHandle(kNearAsDammitEmptyHandleSize);     //handle will be
  626. resized
  627.         
  628.   saveRes = CurResFile();
  629.  
  630.         if (!thePichandle)
  631.                 goto bail;              //PicHandle was NULL so we have nothing to write
  632.         
  633.         HLock((Handle)thePichandle);
  634.         
  635.         iErr = ::Create(theFilename, volumeRefNum, kPictCreatorType,
  636. kPictureType);                          //create the empty file
  637.         if (iErr)
  638.                 goto bail;
  639.  
  640.         iErr = ::FSOpen(theFilename, volumeRefNum, &myFileRef);                                                 //open the
  641. file (data fork only, NOT resource fork...do that bit later)
  642.         if (iErr)
  643.                 {
  644.                 myFileRef = 0;          //set to zero cuz bail routine might try to close the
  645. file...even if unopened
  646.                 goto bail;
  647.                 }
  648.                 
  649.         iErr = ::FSWrite(myFileRef, &byteCount, &pictHeader);                                                   //write the
  650. 512 byte header
  651.         if (iErr)
  652.                 goto bail;
  653.         
  654.         byteCount = ::GetHandleSize((Handle)thePichandle);                                                              //write the
  655. PICT in data fork
  656.         iErr = ::FSWrite(myFileRef, &byteCount, *thePichandle);
  657.         if (iErr)
  658.                 goto bail;
  659.                 
  660.         iErr = ::FSClose(myFileRef);                                                                                                    //close the file
  661.         myFileRef = 0;                                  //set to zero to prevent accidentally closing it
  662. twice...WHICH IS BAD NOOZ!
  663.         if (iErr)
  664.                 goto bail;
  665.                 
  666.         iErr = ::FSMakeFSSpec(volumeRefNum, 0, theFilename, &myFSSpec);                         
  667. //create an FSSpec record
  668.         if (iErr)
  669.                 goto bail;
  670.                 
  671.         ::FSpCreateResFile(&myFSSpec, kPictCreatorType, kPictureType, NULL);
  672. //no error code returned
  673.         if (::ResError())                                                                                               //so we get it from ResError()
  674.                 goto bail;
  675.                 
  676.         myResFile = ::FSpOpenResFile(&myFSSpec, fsRdWrPerm);                                                    //open the
  677. resource file with exclusive read/write permission
  678.         if (ResError())
  679.                 {
  680.                 myResFile = 0;          //set to zero cuz bail routine might try to close the
  681. ResFile, even if unopened, unless fileref is zero
  682.                 goto bail;
  683.                 }
  684.                 
  685.         UseResFile(myResFile);                                                                                                          //tell MacOS that we want to use
  686. this resource file
  687.         if (::ResError())                                                                                               //check for any errors
  688.                 goto bail;
  689.         
  690.         iErr = MakeThumbnailFromPicture(thePichandle, 32, theThumbnail, NULL);          
  691. //create the preview PICT
  692.         if (iErr)
  693.                 goto bail;
  694.         
  695.         iErr = AddFilePreview(myResFile, kPictureType, (Handle)theThumbnail);           
  696. //add the preview picture
  697.         if (iErr)
  698.                 goto bail;
  699.         
  700.         theThumbnail = NULL;    //      prevent our bail routine from deallocating this
  701. because it is now owned by the Resource Manager
  702.         
  703.         //I won't bother checking for errors here
  704.         CloseResFile(myResFile);        //      closeing the res file also updates it
  705.         myResFile = 0;                          //      YOU MUST DO THIS OTHERWISE THE bail ROUTINE WILL
  706. TRY TO CLOSE IT AGAIN AND THAT WILL *CRASH*
  707.  
  708.         result = TRUE;          //yay, all went well
  709.         
  710. bail:
  711.         if (thePichandle)
  712.                 HUnlock((Handle)thePichandle);
  713.         if (myResFile)
  714.                 CloseResFile(myResFile);                //I won't bother checking for errors
  715.         if (myFileRef)
  716.                 iErr = FSClose(myFileRef);              //I'll ignore any error returned here
  717.         if (theThumbnail)
  718.                 DisposHandle((Handle)theThumbnail);
  719.   UseResFile(saveRes);
  720.         return result;
  721. }
  722.  
  723. +++++++++++++++++++++++++++
  724.  
  725. >From Binky the Wonderwhorse <binky@mmcorp.com>
  726. Date: 29 Jan 1996 18:01:11 GMT
  727. Organization: MultiMedia Corporation
  728.  
  729. lo,
  730.  
  731. I forgot...silly me, I totally forgot what you were asking.  It seems I
  732. didn't fully answer your question.
  733.  
  734. Right, now what I think you're trying to do is take an image of whats in
  735. a window, store it as a PICT and then save it out to a file.  I already
  736. posted the code for saving a PicHandle to a file so heres the code for
  737. grabbing whats in a window into a PicHandle.
  738.  
  739. PicHandle
  740. WindowToPicHandle(WindowPtr     theWindow)
  741. {
  742.         CGrafPtr                savePort;
  743.         GDHandle                saveDevice;
  744.         PicHandle       thePic = NULL;
  745.  
  746.         GetGWorld(&savePort, &saveDevice);
  747.         
  748.         SetGWorld((CGrafPtr)theWindow, GetMainDevice());
  749.         ForeColor(blackColor);
  750.         BackColor(whiteColor);
  751.   ClipRect(&theWindow -> portRect);
  752.         thePic = OpenPicture(&theWindow -> portRect);
  753.         CopyBits(&theWindow -> portBits, &theWindow -> portBits, &theWindow ->
  754. portRect, &theWindow -> portRect, srcCopy, NULL);
  755.         ClosePicture();
  756.         SetGWorld(savePort, saveDevice);
  757. }
  758.  
  759.  
  760. So, you call this routine and it returns you the PicHandle.  You then
  761. pass this to the other routine to dump the pic to disk.  To get the pic
  762. size just use GetHandleSize((Handle)thePic);
  763.  
  764. Hope this is what you were after.  If not then mail me and I'll do you a
  765. nice spangly app with source code! (in penance for being stoopid)
  766.  
  767. Binky
  768.  
  769. ---------------------------
  770.  
  771. >From dallas@az.com (Brad & Angie)
  772. Subject: Pascal or C++?
  773. Date: 31 Dec 1995 03:27:31 GMT
  774. Organization: 49N Volleyball
  775.  
  776. Pascal or C++?
  777. So what is the answer?
  778. I am starting a new programming class at the high school level this
  779. January and don't have a compiler yet. We also don't have much money! Does
  780. anyone out there teach computer programming? I will be working on
  781. Macintosh platforms ranging from the LCII to some PowerPC 5200 and 6200
  782. series. I have looked at Symantec Pascal 4.0, but this does not support
  783. PowerPC code. I have Symantec C 6.0 at home, but again no support for PPC.
  784. I am most familiar with the Symantec package, but this is not a major
  785. consideration. I have read the advertising for MetroWorks CodeWarrior 7.0
  786. which supports both C and Pascal, but this costs big bucks.
  787. What do you use?
  788. Any help would be greatly appreciated!
  789. Brad.
  790.  
  791. -- 
  792. Brad & Angie Dallas
  793. dallas@az.com
  794.  
  795. +++++++++++++++++++++++++++
  796.  
  797. >From daniel@cs.colostate.edu (John Daniel)
  798. Date: Sun, 31 Dec 1995 08:46:19 -0700
  799. Organization: Colorado State University
  800.  
  801. Brad & Angie,
  802. You're a student so Codewarrior Academic will only cost you $99.
  803. It will be the best $99 you've ever spent. Go for it.
  804. It has all the features CW Gold has only you can't sell shrink-wrapped
  805. programs with it, only shareware. Order Now!
  806.  
  807. John Daniel
  808.  
  809. -- 
  810. "Just because you're paranoid doesn't mean they aren't out to get you"
  811.  
  812. +++++++++++++++++++++++++++
  813.  
  814. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  815. Date: 31 Dec 1995 12:50:10 GMT
  816. Organization: Integrated Systems Laboratory, ETH, Zurich
  817.  
  818. [Followups redirected to comp.sys.mac.programmer.help]
  819. In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com (Brad & Angie) writes:
  820.  
  821. > Pascal or C++?
  822. > So what is the answer?
  823. > I am starting a new programming class at the high school level this
  824. > January and don't have a compiler yet.
  825.  
  826. For teaching purposes, Pascal is IMHO much better than C++ (Given that for
  827. actual programming, I prefer C++, I don't think anybody can accuse me of
  828. bias).
  829.  
  830. > We also don't have much money! Does anyone out there teach computer
  831. > programming? I will be working on Macintosh platforms ranging from the LCII
  832. > to some PowerPC 5200 and 6200 series. I have looked at Symantec Pascal 4.0,
  833. > but this does not support PowerPC code. I have Symantec C 6.0 at home, but
  834. > again no support for PPC.  I am most familiar with the Symantec package, but
  835. > this is not a major consideration. I have read the advertising for MetroWorks
  836. > CodeWarrior 7.0 which supports both C and Pascal, but this costs big bucks.
  837.  
  838. CodeWarrior for academic purposes officially costs $99, but I've heard of
  839. even lower prices. If that's still too much money for you, you might want to
  840. consider teching Scheme instead, using the free Gambit Scheme. If Scheme is
  841. good enough for MIT, it might be good enough for you :-)
  842.  
  843. Matthias
  844.  
  845. - ---
  846. Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  847.    "Of course the government and the newspapers lie.  But in a 
  848.     democracy they're not the *same* lies!" - GURPS Illuminati
  849.  
  850. +++++++++++++++++++++++++++
  851.  
  852. >From jj10s@eworld.com (J. Voigt)
  853. Date: Sun, 31 Dec 1995 13:18:59 -0600
  854. Organization: (ml)
  855.  
  856. In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com
  857. (Brad & Angie) wrote:
  858.  
  859. > Pascal or C++?
  860. > So what is the answer?
  861. > I am starting a new programming class at the high school level this
  862. > January and don't have a compiler yet. We also don't have much money! 
  863.  
  864. C++ at the highschool level! Yikes!
  865.  
  866. > I have looked at Symantec Pascal 4.0, but this does not support
  867. > PowerPC code. I have Symantec C 6.0 at home, but again no support for PPC.
  868.  
  869. Why does this matter?
  870.  
  871. > I have read the advertising for MetroWorks CodeWarrior 7.0
  872. > which supports both C and Pascal, but this costs big bucks.
  873.  
  874. The Academic version is $99.
  875.  
  876. I don't see any reason to have students grapple with the complex arcana of
  877. low-level languages (Assembly or C) or professional programming languages
  878. (C++)--esp. at the highschool level, if the intent is to teach the basic
  879. concepts of comp.sci.
  880.  
  881. For entry level programming, I'd recommend one of the following:
  882. Logo, Basic, or HyperCard.
  883.  
  884. There are many good introductory programming books for Logo and Basic.
  885.  
  886. If you want to get a bit more sophisticated:
  887. Pascal, Scheme, Mathematica (which offers a very nice dynamic language and
  888. powerful symbolic calculation features).
  889.  
  890. One can of course find many excellent intro.to.prog w/Pascal books. For
  891. Scheme, you might try  Friedman & Felleisen's "The Little Lisper" (or the
  892. second ed., The Little Schemer, coming soon). For Mathematica my personal
  893. favorite is Wagon's "Mathematica in Action".
  894.  
  895. Dewdney's "The New Turing Omnibus" makes for an excellent general comp.sci
  896. text, and is perfect for teaching at the highschool level.
  897.  
  898. Good luck.
  899.  
  900. j ~
  901.  
  902. -- 
  903. J. Voigt / just some guy / not affiliated with anyone or anything
  904. (MediaLink@mail-newrock.coretech.com)
  905.  
  906. +++++++++++++++++++++++++++
  907.  
  908. >From mwron@aol.com (MW Ron)
  909. Date: 31 Dec 1995 14:52:20 -0500
  910. Organization: America Online, Inc. (1-800-827-6364)
  911.  
  912. dallas@az.com (Brad & Angie) Writes:
  913.  
  914. >Pascal or C++?
  915. >So what is the answer?
  916. >I am starting a new programming class at the high school level this
  917. >January and don't have a compiler yet. We also don't have much money!
  918. Does
  919. >anyone out there teach computer programming? I will be working on
  920. >Macintosh platforms ranging from the LCII to some PowerPC 5200 and 6200
  921. >series. I have looked at Symantec Pascal 4.0, but this does not support
  922. >PowerPC code. I have Symantec C 6.0 at home, but again no support for
  923. PPC.
  924. >I am most familiar with the Symantec package, but this is not a major
  925. >consideration. I have read the advertising for MetroWorks CodeWarrior 7.0
  926. >which supports both C and Pascal, but this costs big bucks.
  927. >What do you use?
  928. >Any help would be greatly appreciated!
  929.  
  930. If you are a student or a teacher you are eligible for the Academic Gold
  931. Version of Metrowerks CodeWarrior.  It is just $99, and includes
  932. everything the Gold Professional model includes.
  933.  
  934. We also have a version Programmer Starter Kit for just $79. ( Soon to be
  935. replaced with a Discover Programming CD series by Metrowerks and  Dave
  936. Mark)  While this CD only creates 68k Applications the compilers are FAT
  937. and will run as native on either PowerPC or 68k  and of course the
  938. programs they develop will run on either CPU.  This includes all the
  939. Metrowerks Tools that are included in the Bronze version but it is not a
  940. subscription.
  941.  
  942. Feel Free to write to me for more infomration.
  943. Ron
  944.  
  945.  
  946.    METROWERKS               Ron Liechty
  947. "Software at Work"    MWRon@metrowerks.com
  948.  
  949. +++++++++++++++++++++++++++
  950.  
  951. >From k12baimv@vaxa.hofstra.edu (Vijay Iyer)
  952. Date: 31 Dec 95 17:31:02 EST
  953. Organization: Hofstra University
  954.  
  955. In article <jj10s-3112951318590001@port07.cornet.com>, jj10s@eworld.com (J. Voigt) writes:
  956. > In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com
  957. > (Brad & Angie) wrote:
  958. >> Pascal or C++?
  959. >> So what is the answer?
  960. >> I am starting a new programming class at the high school level this
  961. >> January and don't have a compiler yet. We also don't have much money! 
  962. > C++ at the highschool level! Yikes!
  963.  
  964. > I don't see any reason to have students grapple with the complex arcana of
  965. > low-level languages (Assembly or C) or professional programming languages
  966. > (C++)--esp. at the highschool level, if the intent is to teach the basic
  967. > concepts of comp.sci.
  968. > For entry level programming, I'd recommend one of the following:
  969. > Logo, Basic, or HyperCard.
  970. > There are many good introductory programming books for Logo and Basic.
  971. > If you want to get a bit more sophisticated:
  972. > Pascal, Scheme, Mathematica (which offers a very nice dynamic language and
  973. > powerful symbolic calculation features).
  974. > (MediaLink@mail-newrock.coretech.com)
  975.  
  976.  
  977. Being a high school student, I feel that learning C++ is a better choice for a
  978. slightly higher-level course in a high school. I am presently learning Pascal
  979. in school and C++ at home, and I feel that C++ is more elegant and not
  980. harder to learn than Pascal. I also believe that the Advanced Placement exam in
  981. computer science is shifting from Pascal to either C or C++ within the next two
  982. years, which may or may not be an important consideration.
  983.  
  984. At present, most of our CS class is rebelling as we seem to universally hate
  985. the Pascal in favor of C :-)
  986. -- 
  987. Copyright 1995 Vijay Iyer (k12baimv@hofstra.edu). All rights reserved.
  988. All views represented reflect those of my employer.
  989. http://www.cyberspace.org/u/viyer/www/homepage.html
  990.  
  991. +++++++++++++++++++++++++++
  992.  
  993. >From troy@oz.net (Troy Davis)
  994. Date: Mon, 01 Jan 1996 02:46:26 GMT
  995. Organization: oz.net - http://www.oz.net
  996.  
  997. jj10s@eworld.com (J. Voigt) said:
  998.  
  999. >I don't see any reason to have students grapple with the complex arcana of
  1000. >low-level languages (Assembly or C) or professional programming languages
  1001. >(C++)--esp. at the highschool level, if the intent is to teach the basic
  1002. >concepts of comp.sci.
  1003. >For entry level programming, I'd recommend one of the following:
  1004. >Logo, Basic, or HyperCard.
  1005.  
  1006. Are you kidding? I remember we did Logo on Apple ][E's in 4th grade,
  1007. and HyperCard (barely a language) in 6th grade. I did Basic (and it is
  1008. worthwhile.... some say it teaches bad habits but I don't think so...)
  1009. in 6th grade.
  1010.  
  1011. I'm 14 and starting to learn C. High school is definately not too
  1012. early.
  1013.  
  1014.  
  1015. -=| Troy Davis |=-
  1016. troy@oz.net  -  TroyDavis@aol.com
  1017. http://users.aol.com/TroyDavis/
  1018. Seattle, WA, USA
  1019.  
  1020.  
  1021. +++++++++++++++++++++++++++
  1022.  
  1023. >From t-shinbrot@nwu.edu (Troy Shinbrot)
  1024. Date: Sun, 31 Dec 1995 23:04:53 -0500
  1025. Organization: Northwestern University
  1026.  
  1027. In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com
  1028. (Brad & Angie) wrote:
  1029.  
  1030. > Pascal or C++?
  1031. > So what is the answer?
  1032. > I am starting a new programming class at the high school level this
  1033. > January and don't have a compiler yet. We also don't have much money! Does
  1034. > anyone out there teach computer programming? I will be working on
  1035. > Macintosh platforms ranging from the LCII to some PowerPC 5200 and 6200
  1036. > series. I have looked at Symantec Pascal 4.0, but this does not support
  1037. > PowerPC code. I have Symantec C 6.0 at home, but again no support for PPC.
  1038. > I am most familiar with the Symantec package, but this is not a major
  1039. > consideration. I have read the advertising for MetroWorks CodeWarrior 7.0
  1040. > which supports both C and Pascal, but this costs big bucks.
  1041. > What do you use?
  1042. > Any help would be greatly appreciated!
  1043. > Brad.
  1044.  
  1045. There is no way you would catch me trying to teach C, with or without ++,
  1046. as an introductory language.  It's just too dangerous (in that nothing
  1047. prevents the learning programmer from writing the wrong size data into the
  1048. wrong place, for instance), it's too hard (students can't do a thing until
  1049. they understand the what a pointer is, for example), and the
  1050. learning-to-aggravation ratio is too low.  Moreover, once a student learns
  1051. how basic programming in a relatively simple and painless environment like
  1052. Pascal, it's trivial to turn to C and substitute '{' for 'begin' and so
  1053. forth.
  1054.  
  1055. -Troy
  1056.  
  1057. +++++++++++++++++++++++++++
  1058.  
  1059. >From stevec@accessone.com (Steven Carlson)
  1060. Date: Mon, 01 Jan 1996 08:53:41 -0800
  1061. Organization: :-)
  1062.  
  1063. In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com
  1064. (Brad & Angie) wrote:
  1065.  
  1066. ^Pascal or C++?
  1067. ^So what is the answer?
  1068. ^I am starting a new programming class at the high school level this
  1069. ^January and don't have a compiler yet. We also don't have much money! Does
  1070. ^anyone out there teach computer programming? I will be working on
  1071. ^Macintosh platforms ranging from the LCII to some PowerPC 5200 and 6200
  1072. ^series. I have looked at Symantec Pascal 4.0, but this does not support
  1073. ^PowerPC code. I have Symantec C 6.0 at home, but again no support for PPC.
  1074. ^I am most familiar with the Symantec package, but this is not a major
  1075. ^consideration. I have read the advertising for MetroWorks CodeWarrior 7.0
  1076. ^which supports both C and Pascal, but this costs big bucks.
  1077. ^What do you use?
  1078. ^Any help would be greatly appreciated!
  1079. ^Brad.
  1080. ^
  1081. ^-- 
  1082. ^Brad & Angie Dallas
  1083. ^dallas@az.com
  1084.  
  1085.    I use MW codewarrior C.  In my opinion you should probably teach C and
  1086. not C++.  Pascal, although the syntax isn't as rigid, isn't used as much
  1087. any more and chances are if you were going to do a lot of programming with
  1088. other people you would have to do it in C.  There is also more C source.
  1089.    As far as money goes,  I think MW has a significant academic discount
  1090. for their Academic CodeWarrior. like $99 or something.
  1091.  
  1092. -Steven Carlson stevec@accessone.com
  1093.  
  1094. +++++++++++++++++++++++++++
  1095.  
  1096. >From jj10s@eworld.com (J. Voigt)
  1097. Date: Mon, 01 Jan 1996 14:34:11 -0600
  1098. Organization: (ml)
  1099.  
  1100. [Responding to <troy@oz.net> recent re to my "Re: Pascal or C++" post]
  1101.  
  1102. Troy, I appreciate your response to my post.
  1103.  
  1104. I said:
  1105. > >I don't see any reason to have students grapple with the complex arcana of
  1106. > >low-level languages (Assembly or C) or professional programming languages
  1107. > >(C++)--esp. at the highschool level, if the intent is to teach the basic
  1108. > >concepts of comp.sci.
  1109. > >For entry level programming, I'd recommend one of the following:
  1110. > >Logo, Basic, or HyperCard.
  1111.  
  1112. Then I said (which you had omitted in your response):
  1113. > > If you want to get a bit more sophisticated:
  1114. > > Pascal, Scheme, Mathematica (which offers a very nice dynamic language and
  1115. > > powerful symbolic calculation features).
  1116.  
  1117. You said:
  1118. > Are you kidding? I remember we did Logo on Apple ][E's in 4th grade,
  1119. > and HyperCard (barely a language) in 6th grade. I did Basic (and it is
  1120. > worthwhile.... some say it teaches bad habits but I don't think so...)
  1121. > in 6th grade.
  1122. > I'm 14 and starting to learn C. High school is definately not too
  1123. > early.
  1124.  
  1125. Hey, its great that you got your hands dirty when you were young. I
  1126. suspect, however, that premature exposure to certain programming languages
  1127. has the effect of tainting one's view of them in hindsight. Esp. if one is
  1128. introduced to languages in the classroom and not of one's own volition.
  1129.  
  1130. Logo is a powerful Lisp-derivative. A lot of kids are only introduced to
  1131. the most elementary features of Logo, like turtle-graphics, and get the
  1132. impression that it is simply a "toy" language. Not true; it is a very
  1133. elegant and flexible language, and probably an excellent intro to
  1134. Lisp-style programming.
  1135.  
  1136. Similar statements can be made about Hypercard. It's message passing
  1137. system (and in fact the whole language architecture) is an ideal intro to
  1138. object-oriented programming.
  1139.  
  1140. High school may not be "too early" to learn C for kids with a previous
  1141. exposure to programming languages. However, for an intro to programming I
  1142. would still claim that the above mentioned alternatives are far, far
  1143. better. And for more advanced students, like yourself, a much better
  1144. alternative is Scheme (or some other high-level functional language or
  1145. OODL, like Dylan), which they use for their intro to programming courses
  1146. at MIT--with the Abelson & Sussman text. You might also check out the text
  1147. "Scheme and the Art of Programming" by Daniel P. Friedman & George
  1148. Springer (MIT Press/McGraw Hill, 1989). Here you'll get a real taste of
  1149. computer science, not be stuck dealing with the vagaries of low-level
  1150. syntax (which is what you have to deal with in a language like C).
  1151.  
  1152. -- 
  1153. J. Voigt / just some guy / not affiliated with anyone or anything
  1154. (MediaLink@mail-newrock.coretech.com)
  1155.  
  1156. +++++++++++++++++++++++++++
  1157.  
  1158. >From clyde@hitech.com.au (Clyde Smith-Stubbs)
  1159. Date: Mon, 01 Jan 1996 23:09:25 GMT
  1160. Organization: HI-TECH Software
  1161.  
  1162. On 31 Dec 1995 03:27:31 GMT, dallas@az.com (Brad & Angie) wrote:
  1163.  
  1164. >Pascal or C++?
  1165. >So what is the answer?
  1166. >I am starting a new programming class at the high school level this
  1167. >January and don't have a compiler yet. We also don't have much money! Does
  1168. I personally feel that with a good compiler - one that is fussy about
  1169. possible errors - teaching C at the high-school level is not a
  1170. problem. Certainly don't try C++. Pascal is OK, but gets frustrating
  1171. for anything beyond a simple level. For a cheap compiler, download
  1172. Pacific C from the URL below - for use in your programming class it's
  1173. free, and your students can take a copy home too. The user interface
  1174. is ideal for novice programmers, and the error messages are second to
  1175. none.
  1176.  
  1177. Happy New Year!
  1178.  Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
  1179.  clyde@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
  1180. http://www.hitech.com.au  | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
  1181. - --------------------------------------------------------------------------
  1182. FREE! Download our shareware (FREE for noncommercial use) MS-DOS C Compiler!
  1183.              Point your Web browser at http://www.hitech.com.au/
  1184.  
  1185. +++++++++++++++++++++++++++
  1186.  
  1187. >From pascal@gonzo.wolfenet.com (Jeff Roegner)
  1188. Date: 2 Jan 1996 05:55:44 GMT
  1189. Organization: Wolfe Internet Access, L.L.C.
  1190.  
  1191. As a student who has been in high school and has studied Pascal in the
  1192. A.P. program and is now studying C/C++ under the same program, I can
  1193. honestly say that I recommend Pascal as a language to concider if you are
  1194. creating a computer science curriculum. 
  1195. Reasons for Pascal in your curriculum:
  1196. 1: Easy to learn/understand
  1197. 2: Teaches good habits
  1198. 3: Still/actually used - unlike Hypercard, logo, basic, etc., Pascal is
  1199. actually used
  1200. 4: Good college prep - think how many colleges teach Pascal in their Comp.
  1201. sci 101 classes - every small, private liberal arts college I looked at
  1202. still taught Pascal, and having that knowledge before going into college
  1203. is going to put me ahead in the long run
  1204. 5: Easy tranfer to C/C++  - let's face it,Pascal and C are exactly alike,
  1205. only the syntax changes, it is only in C++ where the differences evolve,
  1206. so once you have the foundation in Pascal,you can then easily change to C
  1207. and thus will have twice the knowledge by knowing both languages
  1208.  
  1209. Reasons against Pascal:
  1210. 1: The A.P. test will be in C/C++ starting in 1999.
  1211. 2: Pascal is not the "language of choice"like it perhaps once was and is
  1212. not as used in the industry as C/C++
  1213.  
  1214. A way to solve the problem for your school may be to teach a "intro to
  1215. comp. sci" class with Pascal and then an "A.P. Computer Sci." class with
  1216. C/C++. We have a similar curriculum with Basic in the intro class and
  1217. Pascal in the A.P. class. We also then have about 6 people in a second
  1218. year A.P. class who are taking C/C++
  1219.  
  1220. In high school, I feel it is important to get a grasp of what computer
  1221. science is all about through the learning of a language, but just learning
  1222. a language isn't really enough to do any hard core programming, that's why
  1223. you go to college and extend upon those basics you learned in high school.
  1224. Pascal is a great foundation, as I am finding as I work on C/C++. The
  1225. bottow line is that so few students in high school are going to be doing
  1226. any major work, that even if you taught them C/C++, what good would it do?
  1227. The key is in planting the foundation for later learning.
  1228.  
  1229. +++++++++++++++++++++++++++
  1230.  
  1231. >From zcemm23@ucl.ac.uk (Guy Ruth Hammond)
  1232. Date: Tue, 2 Jan 1996 13:12:21 GMT
  1233. Organization: Bloomsbury Computing Consortium
  1234.  
  1235. In article <dallas-3012950728570001@ppp31.atlantica.net> dallas@az.com (Brad & Angie) writes:
  1236. >Pascal or C++?
  1237. >So what is the answer?
  1238.  
  1239. Pascal is a good language for learning - it was my first compiled language.
  1240.  
  1241. But it's not used much in industry, there you have C, C++, FORTRAN and COBOL
  1242. (the last two being maintaince of legacy code) and various niche systems
  1243. like VB and Java.
  1244.  
  1245. C is harder to learn than pascal, but when you have learnt it, it's almost
  1246. instinctive to use. I'm just learning C++ now, doing design projects in it
  1247. and things are going swimmingly.
  1248.  
  1249. If you get the academic discount, CW is a lot cheaper!
  1250.  
  1251. >Brad & Angie Dallas
  1252. >dallas@az.com
  1253.  
  1254. *               Guy Ruth Hammond - The Vampire Uustat                *
  1255. * Undergraduate at University College London, Mechanical Engineering *
  1256. * hammond_g@meng.ucl.ac.uk | http://www.ucl.ac.uk/~zcemm23/home.html *
  1257. *   Though I walk through the valley of death I shall fear no evil   *
  1258.  
  1259. +++++++++++++++++++++++++++
  1260.  
  1261. >From sean@corf.demon.co.uk (Sean A Corfield)
  1262. Date: Tue, 02 Jan 1996 15:08:40 +0000
  1263. Organization: OCS
  1264.  
  1265. In article <1996Jan2.131221.13895@ucl.ac.uk>,
  1266. zcemm23@ucl.ac.uk (Guy Ruth Hammond) wrote:
  1267.  
  1268. |> Pascal is a good language for learning - it was my first compiled
  1269. language.
  1270.  
  1271. Likewise...almost. I learnt Algol 60 first (briefly) then BASIC then
  1272. Pascal. Once I started work (over 10 years ago :-) I picked up C easily
  1273. given the grounding in Pascal. For the last four years I've been working
  1274. almost exclusively with C++ and have been involved with the standards
  1275. process too.
  1276.  
  1277. |> C is harder to learn than pascal, but when you have learnt it, it's
  1278. almost
  1279. |> instinctive to use.
  1280.  
  1281. C is also harder to teach if you want students to avoid many of its
  1282. pitfalls. C++ is an order of magnitude harder to teach, and learn, because
  1283. there is a great deal more to absorb in the way of design issues (and any
  1284. course that does not deal with those issues is a failure).
  1285.  
  1286. The CodeWarrior package would be good for Brad & Angie since it provides
  1287. Pascal, C and C++ and the academic price is a bargain.
  1288.  
  1289. Funnily enough, my career (in compiler writing and related jobs) has
  1290. mirrored the progression above: I started writing optimisers for Pascal
  1291. compilers, then worked on a C to Pascal translator (hard: think about
  1292. pointers), then began working on C (and COBOL) compilers -- including the
  1293. first ANSI-validated C compiler. Since then there's been a lot of C++. It's
  1294. a reasonable learning curve spread over a long period of hard experience.
  1295. College courses have a long way to go before they satisfy the needs of
  1296. industry in this area because they often focus on a language instead of on
  1297. problem solving skills and programming per se. Things are definitely
  1298. improving though (from what I see in my role as an external examiner on
  1299. computing courses).
  1300.  
  1301. [sorry, I'm getting a bit off-topic, aren't I?]
  1302.  
  1303. Sean A Corfield
  1304. Object Consultancy Services
  1305. C++ - Beyond the ARM - http://uptown.turnpike.net/~scorf/cplusext.html
  1306.  
  1307.  
  1308.  
  1309.  
  1310. +++++++++++++++++++++++++++
  1311.  
  1312. >From surgsw@mizzou1.missouri.edu (Joel Weinstein)
  1313. Date: Thu, 04 Jan 1996 20:40:10 -0700
  1314. Organization: University of Missouri - Columbia
  1315.  
  1316. I recommend codewarrior academic, unless of course, your high school
  1317. students are planning to make Doom 3, heh heh.
  1318.  
  1319. No need to send this to so many newsgroups.  One would get you an answer.
  1320.  
  1321. +++++++++++++++++++++++++++
  1322.  
  1323. >From user@portal.dx.net (jeremyj)
  1324. Date: 4 Jan 1996 23:08:53 -0500
  1325. Organization: DataXchange Network
  1326.  
  1327. >I'm 14 and starting to learn C. High school is definately not too
  1328. >early.
  1329.  
  1330. I'm 16 years old. I lave taught myself C, C++, Assembler, BASIC, Pascal, 
  1331. UNIX ShellScript, LISP, and a little FORTRAN. Personally, I prefer Pascal 
  1332. or C, due to their compatibilty, support, and respective ease of use. For 
  1333. a high school course, shoot for Pascal or C; Stay away from BASIC, and 
  1334. run from HyperCard; it's more of a toy to most high level programmers 
  1335. (for you HyperCard users, don't get all angry at me. I use HyperCard, 
  1336. even written at least a dozen elaborate stacks for it, but you can't 
  1337. exactly rewrite a copy of X-Wing or remake Stratavision 3d with it). To 
  1338. me, knowing Pascal well has made it easier to learn the other languages, 
  1339. so I'd say that's you're best bet. Go with Codewarrior; If you decide to 
  1340. keep with the times, you can move the class to C or C++ in the future.
  1341.  
  1342. JRJ
  1343. jrj@ring.com
  1344.  
  1345. Please mail me comments.
  1346.  
  1347.  
  1348. +++++++++++++++++++++++++++
  1349.  
  1350. >From <bonnardv@pratique.fr>
  1351. Date: 7 Jan 1996 18:43:27 GMT
  1352. Organization: Internet Way
  1353.  
  1354. jj10s@eworld.com (J. Voigt) wrote:
  1355. >In article <dallas-3012950728570001@ppp31.atlantica.net>, dallas@az.com
  1356. >(Brad & Angie) wrote:
  1357. >
  1358. >> Pascal or C++?
  1359. >> So what is the answer?
  1360. ..
  1361. >For entry level programming, I'd recommend one of the following:
  1362. >Logo, Basic, or HyperCard.d
  1363. >
  1364.  
  1365. What's a good language to learn programming ?
  1366.  
  1367. People who learn programming want to take care of the algorithm, not of 
  1368. the syntax or of the implementation.
  1369.  
  1370. It seem obvious for me that if they want to learn programming 
  1371. *seriously* (not only to write 20-lines programs in Basic) they need a 
  1372. structured language who support sub-programs (or procedures or 
  1373. functions). The 'standard' Basic (the Basic instructions compatibles 
  1374. with most implementations of Basic) doesn't support sub-programs; I know 
  1375. two syntax for sub-programs in Basic, incompatibles with each-other !
  1376.  
  1377. That's the problem with Basic (and some other languages of the same 
  1378. kind): lots of incompatibilities, most books/examples have a specific 
  1379. (and not Macintosh) syntax (even if they express simple things). I 
  1380. believe that it is far easier to write a program (portable or not) 
  1381. longer then 100 lines in Pascal or C then in Basic.
  1382.  
  1383. For all these reasons, I think that languages able to express algorithms 
  1384. with a natural syntax are Pascal, C, C++, Ada...
  1385.  
  1386. The problem with Pascal is that the ISO standard has disappeared under 
  1387. the TurboPascal standard.
  1388.  
  1389. In my opinion, C is the best choice because it is portable, it has a 
  1390. good ANSI library, it has type-checking, and C programs can easily be 
  1391. converted to C++ (an Object Oriented Pascal exists, but C++ is really 
  1392. better).
  1393.  
  1394. Valentin Bonnard
  1395. bonnardv@pratique.fr
  1396.  
  1397.  
  1398.  
  1399. +++++++++++++++++++++++++++
  1400.  
  1401. >From jhalmen@news.abo.fi (Johan Halmen UPR)
  1402. Date: 8 Jan 1996 00:36:15 GMT
  1403. Organization: Abo Akademi University
  1404.  
  1405. bonnardv@pratique.fr wrote:
  1406. : What's a good language to learn programming ?
  1407. : In my opinion, C is the best choice because it is portable, it has a 
  1408. : good ANSI library, it has type-checking, and C programs can easily be 
  1409. : converted to C++ (an Object Oriented Pascal exists, but C++ is really 
  1410. : better).
  1411.  
  1412. If one starts learning programming from scratch¸ I believe Pascal
  1413. is better than C.  It is originally developed for teaching
  1414. programming¸ C was developed for professional programmers to
  1415. develope the Unix system.  I don't say that C is a bad choice¸
  1416. only that it's next to best.  If you don't have the slightest
  1417. idea of what programming is¸ choose Pascal¸ otherwise C.
  1418.  
  1419. Johan Halmen
  1420.  
  1421.  
  1422.  
  1423.  
  1424. +++++++++++++++++++++++++++
  1425.  
  1426. >From andy@ldd.net (Andrew Engle)
  1427. Date: 8 Jan 1996 04:57:46 GMT
  1428. Organization: Southeast Missouri State University
  1429.  
  1430. In article <4cpotv$op9@josie.abo.fi>, jhalmen@news.abo.fi says...
  1431.  
  1432. >If one starts learning programming from scratch¸ I believe Pascal
  1433. >is better than C.  It is originally developed for teaching
  1434. >programming¸ C was developed for professional programmers to
  1435. >develope the Unix system.  I don't say that C is a bad choice¸
  1436. >only that it's next to best.  If you don't have the slightest
  1437. >idea of what programming is¸ choose Pascal¸ otherwise C.
  1438. >
  1439. >Johan Halmen
  1440.  
  1441. Curious that you should make such a post!  In about a week, I will begin my
  1442. first university course that deals with C.  Specifically the course is titled 
  1443. "C and the Unix Environment".  While I'm not exceedingly concerned about the
  1444. Unix portion of the curriculum, the C concerns me.  All my prior Computer 
  1445. Science courses dealt strictly with Pascal (Turbo, to be precise, including the 
  1446. OOP extensions).
  1447.  
  1448. My question to you and any others who may be kind enough to lend a word of 
  1449. advice is what types of pitfalls and other curious things should I be wary of 
  1450. and/or lend additional scrutiny to in my transition from Pascal to C?
  1451.  
  1452. Thank you very much in advance for anything you might send my way.
  1453.  
  1454. Andrew Engle
  1455.  
  1456.  
  1457. +++++++++++++++++++++++++++
  1458.  
  1459. >From stacys@isis.interpac.net (Stacy Sherman)
  1460. Date: 8 Jan 1996 06:14:11 GMT
  1461. Organization: Inter-Pacific Networks
  1462.  
  1463. C should never be used as a first programming language, especially at 
  1464. high school level.  I got my CS degree in '91 and they were teaching most 
  1465. of the courses in Pascal and were just starting to use C.  Even now, the 
  1466. first few courses are still taught in Pascal.
  1467.  
  1468. You want to teach them HOW to program.  Not how to program in C.  It's 
  1469. really easy to screw up & get frustrated in C.  Plus, C relies heavily on 
  1470. pointers which are a difficult concept for many people.
  1471.  
  1472. CodeWarrior academic might be a good choice, or the codewarrior starter 
  1473. kit.  They have both C and Pascal built in.  Just because it can't 
  1474. generate PPC code doesn't mean it can't be used on the PowerMac.  You can 
  1475. run the compiler on the PowerMac and any programs you create with them.  
  1476. The programs won't be native, that's all.
  1477.  
  1478. Stacy
  1479.  
  1480. +++++++++++++++++++++++++++
  1481.  
  1482. >From waldo@buffnet.net (Kevin Eye)
  1483. Date: Mon, 08 Jan 1996 20:38:24 -0500
  1484. Organization: BuffNET
  1485.  
  1486. >: What's a good language to learn programming ?
  1487.  
  1488. I'd have to say Think Pascal is good to learn and about the quickest to
  1489. throw together programs in (of the high level languages/compilers). Don't
  1490. use HyperCard ( It's great and a real advantage of a mac, but it won't get
  1491. you anywhere.) or BASIC. If you learn Pascal, C is simple to learn and
  1492. vice versa, but Think Pascal automates a lot of the tricky compiling
  1493. stuff, but the language is  the same. Maybe I'm biased because I only
  1494. recently got C with CodeWarrior but I still like the Think Pascal
  1495. environment better, especially for beginning.
  1496.  
  1497. +++++++++++++++++++++++++++
  1498.  
  1499. >From gilmoure@mailhost.acc.net (Glenn)
  1500. Date: 10 Jan 1996 00:28:32 GMT
  1501. Organization: acc.net Orlando
  1502.  
  1503. Hi! This is in similar vein. I am in an intro Pascal course at college.
  1504. They use Turbo 7 Pascal for pcs and finished assignments have to run in
  1505. dos. Anyone know of a mac compilar that will spit out dos stuff? CW,
  1506. perhaps? The box didn't mention anything about that. TIA,
  1507.  
  1508. glenn
  1509.  
  1510. -- 
  1511. Gilmoure of Trimaris
  1512. '70 Triumph chopper (project)
  1513.  
  1514. **Think about it, Murray. ... If we could get this baby runnin', we could run over hikers, pick up females, chase down mule deer-man, we'd be the grizzelies from hell.**  G.Larson
  1515.  
  1516. +++++++++++++++++++++++++++
  1517.  
  1518. >From Valentin Bonnard <bonnardv@pratique.fr>
  1519. Date: 10 Jan 1996 12:31:53 GMT
  1520. Organization: Internet Way
  1521.  
  1522. waldo@buffnet.net (Kevin Eye) wrote:
  1523. >>: What's a good language to learn programming ?
  1524. >
  1525. >I'd have to say Think Pascal is good to learn and about the quickest to
  1526. >throw together programs in (of the high level languages/compilers). Don't
  1527. >use HyperCard ( It's great and a real advantage of a mac, but it won't get
  1528. >you anywhere.) or BASIC. If you learn Pascal, C is simple to learn and
  1529. >vice versa, but Think Pascal automates a lot of the tricky compiling
  1530. >stuff, but the language is  the same. Maybe I'm biased because I only
  1531. >recently got C with CodeWarrior but I still like the Think Pascal
  1532. >environment better, especially for beginning.
  1533.  
  1534. I have used Think Pascal and Turbo Pascal for DOS at the same time and tried to run the same programs; the problem with Think Pascal=
  1535.  is the number of incompatibilities with Turbo Pascal, one example:
  1536. procedure foo; ... exit (Foo); { Think, not Turbo }
  1537. procedure foo; ... exit; { Turbo, not Think }
  1538.  
  1539. (But if you wanted to have some compatibility between platforms, you would *not* have chosen Pascal.)
  1540.  
  1541. I had problems in Think Pascal with the editor too: sometimes, when you make a syntax fault, the editor prevents you from correcting=
  1542.  it.
  1543.  
  1544. Valentin Bonnard
  1545. bonnardv@pratique.fr
  1546.  
  1547.  
  1548.  
  1549.  
  1550. +++++++++++++++++++++++++++
  1551.  
  1552. >From Valentin Bonnard <bonnardv@pratique.fr>
  1553. Date: 11 Jan 1996 01:05:31 GMT
  1554. Organization: Internet Way
  1555.  
  1556. andy@ldd.net (Andrew Engle) wrote:
  1557. >My question to you and any others who may be kind enough to lend a word of 
  1558. >advice is what types of pitfalls and other curious things should I be wary of 
  1559. >and/or lend additional scrutiny to in my transition from Pascal to C?
  1560.  
  1561. To understand the following, you should first learn the basic keywords and syntax for functions, blocks...
  1562.  
  1563. I will only point-out the not-so-obvious differences...
  1564.  
  1565. MY notations:
  1566. <=> mean is equivalent to
  1567. -> mean the Pascal code ... 
  1568.  
  1569. In addition to the fact that BEGIN gives { and that there are no DO there are significant differences between Pascal and C.
  1570.  
  1571. First of all:
  1572. * for if else do while return break typedef int short float double... are *reserved* keywords (cannot be used for another thing); no=
  1573.  predefined that can be changed (like WriteLn, ReadChar...).
  1574.  
  1575. * the capitalisation is significant ('For' can be a variable name, but 'for' can only be used for "for (i=1; i<2; i=i+1) or for (i=1=
  1576. ; i<2; i++) since i++ signifies i=i+1".
  1577.  
  1578. The Integers Types
  1579. ==================
  1580. CHAR (8 bits)                   char (sometimes signed, sometimes unsigned,
  1581.                                 write 'unsigned char' to be sure)
  1582. INTEGER (16 bits)               short = short int, *not int*
  1583.                                 int (16 or 32 bits, natural word)
  1584. LONGINT (32 bits)               long = long int
  1585.  
  1586. char is just an integer type, like any others.
  1587.                               ---------------
  1588. The Boolean Type, Some Logic
  1589. ============================
  1590. The BOOLEANs are replaced by int (or Boolean on the Mac, or Bool on PC, each of them defined as int, or short int); TRUE if <> 0, FA=
  1591. LSE if = 0, thus
  1592. IF a THEN /* a being a BOOLEAN */
  1593. -> if (a)  /* a being of any integer type or a pointer to what you want */
  1594. <=> if (a != 0) /* != mean <> */
  1595.  
  1596. IF NOT a THEN
  1597. -> if (!a)  /* NOT -> ! */
  1598. <=> if (a != 0) /* != mean <> */
  1599.  
  1600. TRUE is defined as the integer 1, FALSE as 0
  1601. IF a = FALSE -> if (a == FALSE) <=> if (! a)
  1602.  
  1603. Logical operators
  1604. =================
  1605. and (resp. or) operators are &&,& (||,|)
  1606. if (a && b) if-block else else-block
  1607. <=> if (a) if (b) if-block else else-block
  1608. For && and ||, the second operand is evaluated only if the first doesn't tell the answer (if a is true, that is to say <> 0, a || b =
  1609. is true.
  1610.  
  1611. As a beginner, you should not write that: (well, I do)
  1612. if (a && DoSomethingAndReturnResult)
  1613. /* because DoSomethingAndReturnResult is executed only if a is true, 
  1614.    which is unclear */
  1615.  
  1616. On the contrary, & and | are bit-wise operators (and ^ is the bit-wise XOR), and the two operands are *always* evaluated.
  1617.  
  1618. In TurboPascal, the distinction exists as a flag {S+} or something like that... In Think Pascal this flag doesn't work. So there is =
  1619. an ambiguity in Pascal that don't exist in C.
  1620.  
  1621. Some operators
  1622. ==============
  1623. First, don't forget:
  1624. {Pascal} a := b; -> a = b;
  1625. {Pascal} a = b; -> a == b;
  1626. {Pascal} a <> b; -> a != b;
  1627.  
  1628. You can write:
  1629. a = b;
  1630. a += b; <=> a = a + b;
  1631. a -= b; <=> a = a - b;
  1632. a *= b; <=> a = a * b;
  1633. a /= b; <=> a = a / b; /* for float (Pascal /) and integer (Pascal DIV) */
  1634. a %= b; <=> a = a % b; /* MOD */
  1635. a &= b; <=> a = a & b; /* bit-wise */
  1636. a |= b; <=> a = a | b; /* bit-wise */
  1637. a ^= b; <=> a = a ^ b; /* bit-wise */
  1638. ++a; <=> a += 1; <=> a = a + 1;
  1639. --a; <=> a -= 1; <=> a = a - 1;
  1640.  
  1641. where a is a left-value (something that can be assigned) and b a value
  1642. A left-value is:
  1643. - a variable, member of struct (RECORD), union (RECORD CASE OF), array...
  1644. - *addr, where addr is a value
  1645.  
  1646. ALL of them return the value of 'a' after the computation except a++ and a-- which return the value before the incrementation/decrem=
  1647. entation.
  1648.  
  1649. Functions and Procedures
  1650. ========================
  1651. There is no difference between functions and procedures:
  1652.  
  1653. A procedure is a function that return void (void mean nothing); a statement is simply a expression. These are legal:
  1654. 3; 4+5; a+b+5; /* given a and b are defined */
  1655. a = b = 3; <=> a = (b = 3); <=> b = 3; a = b;
  1656.  
  1657. char    ReadKey (void);
  1658. char    ReadKey ()
  1659. {
  1660.     char key;
  1661.     ......
  1662.     return key;
  1663. }
  1664.  
  1665. char c;
  1666.  
  1667. c = ReadKey (); /* the return value is used */
  1668. ReadKey (); /* this is legal: the return value is not used */
  1669.  
  1670. Note
  1671. ====
  1672. I have wrote here some explanations about what seem to be important for the C beginner; I have forgotten lots of things.
  1673.  
  1674. Valentin Bonnard
  1675. bonnardv@pratique.fr
  1676. 
  1677.  
  1678.  
  1679. +++++++++++++++++++++++++++
  1680.  
  1681. >From gilmoure@mailhost.acc.net (Glenn)
  1682. Date: 10 Jan 1996 00:28:32 GMT
  1683. Organization: acc.net Orlando
  1684.  
  1685. Hi! This is in similar vein. I am in an intro Pascal course at college.
  1686. They use Turbo 7 Pascal for pcs and finished assignments have to run in
  1687. dos. Anyone know of a mac compilar that will spit out dos stuff? CW,
  1688. perhaps? The box didn't mention anything about that. TIA,
  1689.  
  1690. glenn
  1691.  
  1692. -- 
  1693. Gilmoure of Trimaris
  1694. '70 Triumph chopper (project)
  1695.  
  1696. **Think about it, Murray. ... If we could get this baby runnin', we could run over hikers, pick up females, chase down mule deer-man, we'd be the grizzelies from hell.**  G.Larson
  1697.  
  1698. +++++++++++++++++++++++++++
  1699.  
  1700. >From skershaw@scu.edu.au (Shane Kershaw)
  1701. Date: Sat, 13 Jan 1996 11:39:32 +1100
  1702. Organization: Virtual Studios, Faculty of Arts, Southern Cross  University
  1703.  
  1704. In article <4cqcnj$387@pegasus.interpac.net>, stacys@isis.interpac.net
  1705. (Stacy Sherman) wrote:
  1706. >C should never be used as a first programming language, especially at 
  1707. >high school level.  I got my CS degree in '91 and they were teaching most 
  1708. >of the courses in Pascal and were just starting to use C.  Even now, the 
  1709. >first few courses are still taught in Pascal.
  1710. I agree with you here Stacy (where did you do your degree?). Our Uni has
  1711. just changed all of its coding courses and removed Pascal from the
  1712. curriculum entirely. Tis worriesme, especially as they included Visual
  1713. Basic as an example of RAD environemnt (not, I would have thought:-). 
  1714. > You want to teach them HOW to program.  Not how to program in C.  It's 
  1715. > really easy to screw up & get frustrated in C.  Plus, C relies heavily on 
  1716. > pointers which are a difficult concept for many people.
  1717. Again I agree. I stil lthe think that best approach that can be applied
  1718. here is to use the good old pencil and paper compiler for the first
  1719. semester course - don't let them near a machine until they can express
  1720. their intentions algorithmically, this will ultimately lead to better code
  1721. and results for the students, because they won;t be fighting the
  1722. have-I-got-the-right-algorithm battle whilst trying to learn the syntax
  1723. and smemantics of whatever language they are using. One of the best
  1724. things  I liked about my degree was that I was able to do a comparative
  1725. study of languages in the same semester I had to do the cobol unit - C,
  1726. Pascal, Modula2, Cobol and hypertalk (v1.2.5). In some cases what was
  1727. required in the cobol unit algorithmically was also required in the comp
  1728. lang unit, so I was abler to see that the algorithm didn't change, but the
  1729. implementation of the algorithm might, i.e. two lines of code in c, maybe
  1730. 3 in pascal (no ternary if statement) and 6 lines in cobol. It was an eye
  1731. opener and has made me an advocate of algorithm first, implementation
  1732. second approach to coding.
  1733. > CodeWarrior academic might be a good choice, or the codewarrior starter 
  1734. > kit.  They have both C and Pascal built in.  Just because it can't 
  1735. > generate PPC code doesn't mean it can't be used on the PowerMac.  You can 
  1736. > run the compiler on the PowerMac and any programs you create with them.  
  1737. > The programs won't be native, that's all.
  1738. Uum, I wansn't aware that this was the case - I use CW academic and don't
  1739. have any problem generating PPC only code. The only limitation of CW
  1740. academic is that you can't sell your programs - no more, no less.
  1741.  
  1742. Shane
  1743. -- 
  1744. Shane Kershaw
  1745. Co-moderator of sci.psychology.research
  1746. Systems Administration, Virtual Studios
  1747. Southern Cross University, NSW Australia
  1748.  
  1749. +++++++++++++++++++++++++++
  1750.  
  1751. >From tblancha@evolving.com (Todd Blanchard)
  1752. Date: 23 Jan 1996 00:26:52 GMT
  1753. Organization: Evolving Systems, Inc.
  1754.  
  1755. Shane Kershaw (skershaw@scu.edu.au) wrote:
  1756. : In article <4cqcnj$387@pegasus.interpac.net>, stacys@isis.interpac.net
  1757. : (Stacy Sherman) wrote:
  1758. : >C should never be used as a first programming language, especially at 
  1759. : >high school level.  I got my CS degree in '91 and they were teaching most 
  1760. : >of the courses in Pascal and were just starting to use C.  Even now, the 
  1761. : >first few courses are still taught in Pascal.
  1762.  
  1763. Well, I teach CS at Univ of Colorado Denver and we've started to do our
  1764. data structures class using C++.  Its more strongly typed than C so its a
  1765. bit safer to learn with.
  1766.  
  1767. RE: Pointers are difficult - yes they are, but all truly powerful concepts
  1768. are.  For teaching algorithms, it is hard to beat C.  
  1769.  
  1770.  
  1771. - ---------------------------------------------------------------------
  1772. Todd Blanchard                                    tblancha@evolving.com
  1773. Evolving Systems Inc.                               VOX: (303) 689-1798
  1774.                                                     FAX: (303) 689-1399
  1775. When the only hammer you have is C++, the whole world looks like a thumb.
  1776. - ---------------------------------------------------------------------
  1777.  
  1778. +++++++++++++++++++++++++++
  1779.  
  1780. >From jeisenstein@wesleyan.edu (Jacob Eisenstein)
  1781. Date: Sat, 27 Jan 1996 14:38:04 -0500
  1782. Organization: Wesleyan University
  1783.  
  1784. In article <waldo-0801962038240001@dppp21.buffnet.net>, waldo@buffnet.net
  1785. (Kevin Eye) wrote:
  1786.  
  1787. > >: What's a good language to learn programming ?
  1788. > I'd have to say Think Pascal is good to learn and about the quickest to
  1789. > throw together programs in (of the high level languages/compilers). Don't
  1790.  
  1791. Actually, I've just begun to learn both Pascal and C++ in the last month,
  1792. and I think they're of about equal difficulty.  That said, I'd favor C++
  1793. simply from the standpoint of how often you will want to use it in the
  1794. future.  
  1795.  
  1796. > Don't use HyperCard ( It's great and a real advantage of a mac, but it won't 
  1797. > get you anywhere.) or BASIC. 
  1798.  
  1799. My preference is a lisp variant, Scheme.  For Mac, get MacGambit.  Scheme
  1800. teaches good programming habits, and a lot of important basic concepts. 
  1801. Scheme will help you write good solid programs in other languages. 
  1802. Biggest disadvantage: it isn't used for anything besides teaching computer
  1803. science.  So if you want to be using a marketable language immediately,
  1804. C++ is your best bet.
  1805.  
  1806. -jacob
  1807.  
  1808. ---------------------------
  1809.  
  1810. >From matsrc@hofstra.edu (Steven R. Costenoble)
  1811. Subject: PixMap pmVersion field
  1812. Date: Thu, 18 Jan 1996 16:30:18 -0500
  1813. Organization: Hofstra University
  1814.  
  1815. Does anyone know what the possible values are of the pmVersion field of a
  1816. PixMap, and what they mean?
  1817.  
  1818. I just ran into a nasty problem that froze a IIci running 7.1 badly (mouse
  1819. frozen, can't break into MacsBug with the programmer's button). I want to
  1820. cache an image by CopyBitsing it into a PixMap that I allocate by hand. I
  1821. call NewPixMap to create the PixMapHandle, allocate the storage myself and
  1822. also reset the color table to the current port's table. NewPixMap copies
  1823. most of the PixMap fields from the current port, including pmVersion,
  1824. which is 2 (on the IIci running Sys 7.1). I do my drawing in an offscreen
  1825. GWorld (created using NewGWorld). Then I try to CopyBits from the GWorld
  1826. to the PixMap, and the computer freezes. After some investigation I notice
  1827. that the pmVersion of the GWorld is 1 and of the PixMap is 2. Changing the
  1828. pmVersion of the PixMap to 1 fixes the problem.
  1829.  
  1830. Inside Macintosh is no help; it seems to say that the only possible values
  1831. are 0 and 32. Also, the same code worked perfectly well on a PPC 7100
  1832. running MacOS 7.5.1, both as PPC code and as emulated 68K code (I haven't
  1833. had a chance to go back and check the pmVersion fields there yet). Any
  1834. ideas?
  1835.  
  1836. --Steve Costenoble             matsrc@hofstra.edu
  1837.   Dept. of Mathematics
  1838.   Hofstra University
  1839.  
  1840. +++++++++++++++++++++++++++
  1841.  
  1842. >From cameron_esfahani@powertalk.apple.com (Cameron Esfahani)
  1843. Date: Tue, 23 Jan 1996 02:08:36 -0800
  1844. Organization: Apple Computer, Inc.
  1845.  
  1846. The current port when you called NewPixMap must have been a GWorld.  The
  1847. pmVersion is used by Quickdraw to store some state.  If the pmVersion
  1848. field is 1, that means the baseAddr field is a pointer to the data.  If
  1849. the pmVersion field is 2, that means the baseAddr field is a handle to the
  1850. data.  Since you have put a pointer into the baseAddr field, if the
  1851. pmVersion is 2, Quickdraw will try to double dereference your baseAddr and
  1852. crash.
  1853.  
  1854. When you call NewPixMap, make sure a GWorld is not the current port.
  1855.  
  1856. Cameron Esfahani
  1857.  
  1858. +++++++++++++++++++++++++++
  1859.  
  1860. >From njaharve@undergrad.math.uwaterloo.ca (Nick Frosh)
  1861. Date: Thu, 25 Jan 1996 23:49:37 GMT
  1862. Organization: University of Waterloo
  1863.  
  1864. In article <cameron_esfahani-2301960208360001@17.202.33.245>,
  1865. Cameron Esfahani <cameron_esfahani@powertalk.apple.com> wrote:
  1866. >The pmVersion is used by Quickdraw to store some state.  If the pmVersion
  1867. >field is 1, that means the baseAddr field is a pointer to the data.  If
  1868. >the pmVersion field is 2, that means the baseAddr field is a handle to the
  1869. >data.
  1870.  
  1871. Is this documented? Are we supposed to use this technique, or should we not
  1872. be fiddling around with the private QuickDraw variables?
  1873.  
  1874. Thanks,
  1875. Nick
  1876. -- 
  1877.                                                                -------
  1878. /----------------------------------------------------------- ( __   __ ) --\
  1879. |                    nick.harvey@pobox.com                    \\_) (_//    |
  1880. |            http://calum.uwaterloo.ca/u/njaharve/             \  "  /     |
  1881.  
  1882. +++++++++++++++++++++++++++
  1883.  
  1884. >From cameron_esfahani@powertalk.apple.com (Cameron Esfahani)
  1885. Date: Tue, 30 Jan 1996 02:55:49 -0800
  1886. Organization: Apple Computer, Inc.
  1887.  
  1888. Jesus Christ, no!
  1889.  
  1890. Call LockPixels and UnlockPixels.
  1891.  
  1892. Cameron Esfahani
  1893.  
  1894.  
  1895. ---------------------------
  1896.  
  1897. >From fettig@cloister (Thomas Fettig)
  1898. Subject: TextEdit: how to stay in one line?
  1899. Date: 25 Jan 1996 15:57:39 GMT
  1900. Organization: DFKI - German Research Center for Artificial Intelligence
  1901.  
  1902.  
  1903. Hi,
  1904.  
  1905. it seems that the TextEdit-Routines have no special mode
  1906. to keep the text in one line and scroll the characters horizontally.
  1907. Am right with this observation? How do i prevent the destination
  1908. rectangle from growing to the bottom? I.e which hooks are to set?
  1909. I'm sure many programmers have solved this problem, so perhaps
  1910. there is source-code anywhere?
  1911.  
  1912.         tom
  1913.  
  1914.  
  1915.  
  1916. +++++++++++++++++++++++++++
  1917.  
  1918. >From jayfar@netaxs.com (Jay Farrell)
  1919. Date: Thu, 25 Jan 1996 12:04:14 -0500
  1920. Organization: Jayfar's Web
  1921.  
  1922. In article <FETTIG.96Jan25165739@cloister>, fettig@cl.dfki.uni-sb.de wrote:
  1923.  
  1924. | Hi,
  1925. | it seems that the TextEdit-Routines have no special mode
  1926. | to keep the text in one line and scroll the characters horizontally.
  1927. | Am right with this observation? How do i prevent the destination
  1928. | rectangle from growing to the bottom? I.e which hooks are to set?
  1929. | I'm sure many programmers have solved this problem, so perhaps
  1930. | there is source-code anywhere?
  1931.  
  1932. Put a negative value in the CRonly field of your TE record.
  1933.  
  1934. Cheers,
  1935. Jayfar
  1936.  
  1937.    ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  1938.   ////   The Mops Page    <URL:http://www.netaxs.com/~jayfar/mops.html>    ////
  1939.  ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  1940. ////   Mops is Mike Hore's freeware Forth/Smalltalk hybrid for Macintosh ////
  1941. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1942.   Jay Farrell     jayfar@netaxs.com        Philadelphia, Pennsylvania, USA
  1943.  
  1944. +++++++++++++++++++++++++++
  1945.  
  1946. >From fettig@cloister (Thomas Fettig)
  1947. Date: 25 Jan 1996 22:39:51 GMT
  1948. Organization: DFKI - German Research Center for Artificial Intelligence
  1949.  
  1950.  
  1951. thanks to jayfar@netaxs.com (Jay Farrell) for the answer:
  1952.  
  1953. >Put a negative value in the CRonly field of your TE record.
  1954.  
  1955. perhaps this thread should be in  the next csmp-digest? 
  1956.  
  1957.         tom
  1958.  
  1959. +++++++++++++++++++++++++++
  1960.  
  1961. >From pottier@drakkar.ens.fr (Francois Pottier)
  1962. Date: 26 Jan 1996 10:44:33 GMT
  1963. Organization: Ecole Normale Superieure, Paris
  1964.  
  1965. In article <FETTIG.96Jan25233951@cloister>,
  1966. Thomas Fettig <fettig@cl.dfki.uni-sb.de> wrote:
  1967.  
  1968. >perhaps this thread should be in  the next csmp-digest? 
  1969.  
  1970. Don't worry, Big Brother is watching you.
  1971.  
  1972.  
  1973. -- 
  1974. Francois
  1975. pottier@dmi.ens.fr
  1976. http://www.eleves.ens.fr:8080/home/pottier/
  1977.  
  1978. ---------------------------
  1979.  
  1980. >From dubois@night.primate.wisc.edu (Paul DuBois)
  1981. Subject: TransSkel 3.24 is available (CW 8 support added)
  1982. Date: 25 Jan 1996 15:45:38 -0600
  1983. Organization: UW-Madison Primate Center
  1984.  
  1985.  
  1986. Release 3.24 of TransSkel, a skeleton for Macintosh application development
  1987. under MetroWerks C or Pascal or Symantec C++/THINK C, is now available.
  1988.  
  1989. This is an update release; the Metrowerks projects have been updated
  1990. to compile under CodeWarrior 8.  Otherwise it's identical to release
  1991. 3.23.
  1992.  
  1993. The documentation is available separately, in either Word 6 or RTF
  1994. format.
  1995.  
  1996. TransSkel is available via any of the following:
  1997.  
  1998. WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/
  1999.  
  2000. anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel)
  2001.  
  2002. gopher to gopher.primate.wisc.edu, then select "Primate Center Software
  2003. Archives")
  2004. -- 
  2005. Paul DuBois
  2006. dubois@primate.wisc.edu
  2007. Home page: http://www.primate.wisc.edu/people/dubois
  2008.  Software: http://www.primate.wisc.edu/software
  2009.  
  2010. +++++++++++++++++++++++++++
  2011.  
  2012. >From pcastine@prz.tu-berlin.de (Peter Castine)
  2013. Date: Fri, 26 Jan 1996 15:50:09 +0100
  2014. Organization: Process Control Center, TU Berlin
  2015.  
  2016. In article <4e8tm2$hr9@night.primate.wisc.edu>,
  2017. dubois@night.primate.wisc.edu (Paul DuBois) wrote:
  2018.  
  2019. >TransSkel is available via any of the following:
  2020. >
  2021. >WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/
  2022. >
  2023. >anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel)
  2024.  
  2025. Any mirror sites, maybe east of the Atlantic Ocean? Right now FTP is
  2026. getting me about 20 bytes/s over from Wisconsin, I think I'm gonna have to
  2027. kill the connection.
  2028.  
  2029. Thanks,
  2030.  
  2031. Peter
  2032.  
  2033. - -------- For a good time, http://www.prz.tu-berlin.de/~pcastine ---------
  2034. Dr. Peter Castine           | Whenever I hear anyone arguing for slavery, I
  2035. pcastine@prz.tu-berlin.de   | feel a strong impulse to see it tried on him
  2036. Process Control Center      | personally.
  2037. Technical University Berlin |                            -- Abraham Lincoln
  2038.  
  2039. ---------------------------
  2040.  
  2041. >From verec@micronet.fr (Jean-Francois Brouillet)
  2042. Subject: WorldScript, UniCode & Cross-Platform ?
  2043. Date: Fri, 26 Jan 1996 16:25:25 +0100
  2044. Organization: Francenet -- Paris, France
  2045.  
  2046. Hi all!
  2047.  
  2048. I'm writing a Macintosh app which is to share its files with its Windows's
  2049. counterpart beeing written now. Among the data we have to share, we have
  2050. user entered text.
  2051.  
  2052. As far as I get a complete picture, I don't seem to see a way we could get
  2053. both cross-platform AND international support :
  2054.  
  2055. WorldScript supports a mixture of 1-byte & 2-byte codes.
  2056. WorldScript doesn't support UniCode yet.
  2057.  
  2058. Windows95/Windows NT supports both 1 & 2 bytes characters (Mac
  2059. incompatible) mixture plus UniCode (Windows95 doesn't directly support
  2060. UniCode, but has ways to translate back and forth between its native
  2061. format and UniCode).
  2062.  
  2063. My best bet seem to be to go with UniCode, as its support is announced for
  2064. Copland, but in the meantime I need ways to convert back and forth between
  2065. WorldScript multi-byte encoding and UniCode.
  2066.  
  2067. Anyone has already done similar things ?
  2068. Any pointer ?
  2069. Where can I find the complete UniCode Specs ?
  2070.  
  2071. -- 
  2072. Jean-Francois Brouillet              verec@micronet.fr
  2073. Macintosh Software Developer     verecundus@eworld.com
  2074.  
  2075. +++++++++++++++++++++++++++
  2076.  
  2077. >From kris@hawkins.ecn.purdue.edu (Kris L Jorgensen)
  2078. Date: 26 Jan 1996 16:45:37 GMT
  2079. Organization: Purdue University, W. Lafayette, IN
  2080.  
  2081. Jean-Francois Brouillet (verec@micronet.fr) wrote:
  2082. > Hi all!
  2083.  
  2084. > I'm writing a Macintosh app which is to share its files with its Windows's
  2085. > counterpart beeing written now. Among the data we have to share, we have
  2086. > user entered text.
  2087.  
  2088. > As far as I get a complete picture, I don't seem to see a way we could get
  2089. > both cross-platform AND international support :
  2090.  
  2091. > WorldScript supports a mixture of 1-byte & 2-byte codes.
  2092. > WorldScript doesn't support UniCode yet.
  2093.  
  2094. > Windows95/Windows NT supports both 1 & 2 bytes characters (Mac
  2095. > incompatible) mixture plus UniCode (Windows95 doesn't directly support
  2096. > UniCode, but has ways to translate back and forth between its native
  2097. > format and UniCode).
  2098.  
  2099. > My best bet seem to be to go with UniCode, as its support is announced for
  2100. > Copland, but in the meantime I need ways to convert back and forth between
  2101. > WorldScript multi-byte encoding and UniCode.
  2102.  
  2103. > Anyone has already done similar things ?
  2104. > Any pointer ?
  2105. > Where can I find the complete UniCode Specs ?
  2106.  
  2107. You might want to get the book "Understanding Japanese Information
  2108. Processing" which describes how to do what you want.  Ken Lunde, the
  2109. author, has provided code to convert between the various different
  2110. encoding methods used through out the world.  You can get the code from
  2111. <ftp://ftp.ora.com/pub/examples/nutshell/ujip/src/jconv.c>.  Information
  2112. about the book can be had from 
  2113. <http://www.ora.com/gnn/bus/ora/item/ujip.html>.  You can even order the 
  2114. book from this site.  I'm including the book information below.  As far as
  2115. Unicode is concerned try the Unicode home page at
  2116. <http://www.stonehand.com/unicode.html>.  I hope this helps.
  2117.  
  2118. Understanding Japanese Information Processing
  2119.  
  2120. By Ken Lunde 
  2121. 1st Edition September 1993
  2122. ISBN: 1-56592-043-0, Order Number: 0430
  2123. 470 pages, $29.95 
  2124.  
  2125. This book provides detailed information on all aspects of handling
  2126. Japanese text on computer systems. It covers everything from the
  2127. origins of modern-day Japanese to the latest information on specific
  2128. emerging computer encoding standards. Appendices provide additional
  2129. reference material: a code conversion table, character set tables,
  2130. mapping tables, an extensive list of software sources, a glossary, and
  2131. more. 
  2132.  
  2133.  
  2134.  
  2135. --
  2136. Kris L. Jorgensen
  2137. Office:     ME 183
  2138. Phone:      (317) 494-8585
  2139. Email:      kris@ecn.purdue.edu
  2140. WWW:        http://widget.ecn.purdue.edu/~kris
  2141.  
  2142. +++++++++++++++++++++++++++
  2143.  
  2144. >From Peter De Mangelaere <pdmangel@eps.agfa.be>
  2145. Date: Mon, 29 Jan 1996 09:50:22 +0000
  2146. Organization: Agfa-Gevaert N.V.
  2147.  
  2148. See the "Unicode Convertor" folder on the "Mac TechSeed Jan '96" CD.
  2149. There's documentation and dummy libraries (?) and an extension.
  2150. I haven't looked deep into it yet.
  2151.  
  2152. The complete UniCode Spec : 
  2153.    The Unicode Standard - Worldwide Character Encoding Version 1.0,
  2154.    The Unicode Consortium, Addison - Wesley
  2155.  
  2156. -- 
  2157.                                           """
  2158.  ___     _                              <(o o)>
  2159. | _ \___| |_ ___ _ _  +--------------oOO--(_)--OOo------------------+
  2160. |  _/ -_)  _| -_) '_| | Peter De Mangelaere, Agfa-Gevaert, Belgium  |
  2161. |_| \___|_| \___|_|   |           pdmangel@eps.agfa.be                                                          |
  2162.                       +---------------------------------------------+
  2163.                                          /\ /\
  2164.                                         oOO OOo
  2165.  
  2166. +++++++++++++++++++++++++++
  2167.  
  2168. >From dpolasch@apple.com (Dave Polaschek)
  2169. Date: Wed, 31 Jan 1996 23:26:12 GMT
  2170. Organization: Apple Computer, Inc
  2171.  
  2172. In article <verec-2601961625250001@ppp104.micronet.fr>, verec@micronet.fr
  2173. (Jean-Francois Brouillet) wrote:
  2174.  
  2175. >Where can I find the complete UniCode Specs ?
  2176.  
  2177. The Unicode home page is at <http://www.stonehand.com/unicode.html>.
  2178.  
  2179. -- 
  2180. "Mr. Tick, can you destroy the Earth?"
  2181. "Egads! I hope not! That's where I keep all my stuff!"
  2182. Dave Polaschek - home:davep@eworld.com work:dpolasch@apple.com
  2183.  
  2184. ---------------------------
  2185.  
  2186. >From dnebing@epix.net (Dave Nebinger)
  2187. Subject: [Ann] The alt.sources.mac WWW Archive
  2188. Date: Tue, 30 Jan 1996 14:32:31 -0500
  2189. Organization: KHP Services, Inc
  2190.  
  2191.  
  2192. The alt.sources.mac archive is now available on the world wide web.
  2193. Point your browsers at:
  2194.   <http://www.AmbrosiaSW.com/alt.sources.mac/>
  2195.  
  2196. Dave.
  2197.  
  2198. ==========================================================
  2199. Dave Nebinger                             dnebing@epix.net
  2200.              The Alt.Sources.Mac Archivist
  2201.      <http://www.AmbrosiaSW.com/alt.sources.mac/>
  2202.     <ftp://ftp.AmbrosiaSW.com/pub/alt.sources.mac/>
  2203.  
  2204. ---------------------------
  2205.  
  2206. >From gneufeld@ccs.carleton.ca (G. Neufeld)
  2207. Subject: [src] Grant's CGI Framework beta 13 (mac C source)
  2208. Date: Fri, 26 Jan 1996 10:53:50 GMT
  2209. Organization: Carleton University
  2210.  
  2211. Grant's CGI Framework
  2212. Version 1.0 beta 13
  2213. <http://arpp.carleton.ca/grant/mac/grantscgi/>
  2214.  
  2215. Grant's CGI Framework is a framework for writing 68K & PowerPC Macintosh
  2216. CGI applications in C. The user of the framework only needs to modify
  2217. one function (located in its own file) to produce a custom CGI - all the
  2218. other details can be left to the framework. However, there are numerous
  2219. options for customization available for those who need them.
  2220.  
  2221. Macintosh programming experience is not required (although it helps) -
  2222. but at least a basic knowledge of the ANSI C language is required.
  2223.  
  2224. New in beta 13:
  2225.  
  2226.  * Easier menu customization
  2227.  * A number of new utility functions
  2228.  * Many bug fixes (some critical fixes)
  2229.  
  2230. Features:
  2231.  
  2232.  * 68K and PowerPC native support
  2233.  * Multi-Threaded (thread support requires Apple's Thread Manager
  2234.    or System 7.5)
  2235.  * Automatic html form parsing with easy function access to
  2236.    individual fields
  2237.  * Supports Asynchronus CGI (ACGI)
  2238.  * Supports ListSTAR trigger and action events
  2239.  * AppleScriptable for testing without a server or MacTCP
  2240.  * Can optionally compile as faceless background-only application
  2241.  * Numerous configuration options for optimizing to your specific needs
  2242.  * Option for self-quitting after specified idle time
  2243.  * Significant performance increase over scripts such as those in
  2244.    AppleScript and Perl
  2245.  * Metrowerks and Symantec project files
  2246.  * If you use it to write free applications, it's free to use.
  2247.    Otherwise, there is a price.
  2248.  
  2249.  
  2250. Download:
  2251.   <http://arpp.carleton.ca/grant/mac/grantscgi.sit.hqx>
  2252.   (b13 soon to be on the Info-Mac archives)
  2253.  
  2254. Mailing List:
  2255.   To: grantcgi@arpp1.carleton.ca
  2256.   Subject: subscribe
  2257.  
  2258. -- 
  2259. gneufeld@ccs.carleton.ca - grant@acm.org <http://arpp.carleton.ca/grant/>
  2260.  
  2261. ---------------------------
  2262.  
  2263. >From ghentsch@hookup.net (Georg Hentsch)
  2264. Subject: calculating height of a text box
  2265. Date: 21 Jan 1996 21:39:00 GMT
  2266. Organization: Bannister Lake Software
  2267.  
  2268. I need to calculate the height of a text box. Given the string, the font &
  2269. the width of the box, how can I calculate the height of my text box? Is
  2270. there 1 toolbox call or should I be using a combination of MeasureText &
  2271. TextWidth?
  2272.  
  2273. Regards, Georg
  2274.  
  2275. -- 
  2276. Georg Hentsch, Bannister Lake Software
  2277. ghentsch@hookup.net
  2278.  
  2279. +++++++++++++++++++++++++++
  2280.  
  2281. >From heaney@crl.com (John S. Heaney)
  2282. Date: 21 Jan 1996 16:32:58 -0800
  2283. Organization: CRL Dialup Internet Access        (415) 705-6060  [Login: guest]
  2284.  
  2285. In article <ghentsch-2101961635220001@ghentsch.wat.hookup.net>,
  2286. Georg Hentsch <ghentsch@hookup.net> wrote:
  2287. >I need to calculate the height of a text box. Given the string, the font &
  2288. >the width of the box, how can I calculate the height of my text box? Is
  2289. >there 1 toolbox call or should I be using a combination of MeasureText &
  2290. >TextWidth?
  2291.  
  2292. Just create a new TextEdit record with TENew or TEStylNew. Then call
  2293. TEGetHeight, which takes the first and last line of interest to you. I'm
  2294. pretty sure these values are zero based, so you would want to use 0 for
  2295. the start line and TERec.nLines-1 for the end line. There is something
  2296. weird about having a CR as the last character of your text. Apparently, 
  2297. it underestimates the number of lines by one in this case.
  2298.  
  2299. Here's the pertinent C code from an old Think C project:
  2300.  
  2301. /******************************************************************************
  2302.  GetNumLines
  2303.  
  2304.         Return the number of lines of text.
  2305. ******************************************************************************/
  2306.  
  2307. long CEditText::GetNumLines( void)
  2308. {
  2309.         long numLines = (**macTE).nLines;
  2310.         long teLen = (**macTE).teLength;
  2311.  
  2312. /* TE line count is not correct if      */
  2313. /*   last char is a carriage return     */
  2314.         if ((teLen > 0) && ((*(**macTE).hText)[ teLen - 1] == CARRIAGE_RETURN))
  2315.                 numLines++;
  2316.                 
  2317.         return numLines;
  2318. }
  2319.  
  2320. /******************************************************************************
  2321.  GetHeight
  2322.  
  2323.         Return the height in pixels of the indicated lines of text.
  2324. ******************************************************************************/
  2325.  
  2326. long CEditText::GetHeight( long startLine, long endLine)
  2327. {
  2328.         long                    height;
  2329.  
  2330.         height = TEGetHeight( endLine+1, startLine+1, macTE);
  2331.         return height;
  2332. }
  2333.  
  2334. This will be a snap to implement in Prograph. ;)  Actually, I'll be doing 
  2335. that myself in the near future, so warn me if you have any problems.
  2336.  
  2337. -- 
  2338. John Heaney              Time flies whether you're having fun or not.
  2339. heaney@crl.com
  2340.  
  2341. +++++++++++++++++++++++++++
  2342.  
  2343. >From dbrosius@chesco.com (Dave Brosius)
  2344. Date: 29 Jan 1996 05:18:23 GMT
  2345. Organization: Chester County Internet Services, Inc.
  2346.  
  2347. In article <ghentsch-2101961635220001@ghentsch.wat.hookup.net>,
  2348. ghentsch@hookup.net (Georg Hentsch) wrote:
  2349.  
  2350. > I need to calculate the height of a text box. Given the string, the font &
  2351. > the width of the box, how can I calculate the height of my text box? Is
  2352. > there 1 toolbox call or should I be using a combination of MeasureText &
  2353. > TextWidth?
  2354. > Regards, Georg
  2355. > -- 
  2356. > Georg Hentsch, Bannister Lake Software
  2357. > ghentsch@hookup.net
  2358.  
  2359. GetFontInfo will return a fontinforec which has ascent, descent and
  2360. leading for a font/size/style
  2361.  
  2362. ---------------------------
  2363.  
  2364. End of C.S.M.P. Digest
  2365. **********************
  2366.